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CHAPTER  1 


Introduction 

The  increasing  use  of  computers  in  day-to-day  life  has  placed  demand  on 
computing  that  is  beyond  the  capabilities  of  current  computer  systems.  This 
demand  can  be  met  either  by  increasing  speed  of  uniprocessor  systems  or  by 
increasing  the  number  of  processors  in  multi-processor  systems.  We  call  com¬ 
puter  systems  that  use  more  than  one  processor,  concurrent  systems.  The 
current  hardware  technology  favors  concurrent  systems  by  making  it  more 
economical  to  provide  high  MIPS  (million  of  instructions  per  second)  by  multi¬ 
ple  processors  rather  than  uniprocessors.  In  this  dissertation,  we  will  restrict 
ourselves  to  concurrent  systems. 

A  concurrent  system  that  consists  of  processors  which  execute  in  a  lock- 
step  manner  is  called  a  synchronous  system.  A  concurrent  system  in  which 
processors  are  loosely  coupled  and  execute  independently  of  each  other  is 
called  an  asynchronous  system.  Processors  in  an  asynchronous  system  do  not 
share  the  clock;  therefore,  it  is  easier  to  increase  the  number  of  processors  in 
an  asynchronous  system  than  in  a  synchronous  system.  This  dissertation  deals 
only  with  asynchronous  concurrent  systems. 

Asynchronous  concurrent  systems  can  further  be  classified  into  shared 
memory  based  and  message  based  architectures.  We  call  shared  memory  based 
systems,  parallel.  These  systems  assume  that  processors  communicate  with 
each  other  by  writing  and  reading  in  shared  memory  locations.  Concurrent 
systems  that  consist  of  multiple  computers  connected  by  a  communication  net- 
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work  are  called  distributed  systems.  Distributed  systems  offer  many  advan¬ 
tages  over  parallel  systems.  These  advantages  are  as  follows: 

(1)  Distributed  systems  provide  load  sharing  to  better  exploit  available 
processing  capacity. 

(2)  Distributed  systems  provide  resource  sharing. 

(3)  Distributed  systems  provide  data  sharing  as  in  distributed  databases. 

(4)  The  geographical  structure  may  be  inherently  distributed.  The  low 
communication  bandwidth  may  force  local  processing. 

(5)  The  logical  structure  may  be  simpler,  e.g.  if  each  local  process  is 
located  in  a  separate  processor. 

(6)  The  reliability  of  a  system  can  be  enhanced.  Distributed  systems  are 
more  reliable  because  the  failure  of  a  single  computer  does  not  affect  the 
availability  of  others. 

(7)  The  flexibility  of  a  system  is  increased  because  a  single  processor  can 
be  added  or  deleted  easily. 

(8)  Availability  of  high  bandwidth  network  and  cheap  diskless  worksta¬ 
tions  also  favors  distributed  computing  for  economic  reasons. 

This  dissertation  deals  only  with  message  based  concurrent  systems.  By 
concurrent  systems  we  would  mean  distributed  systems  unless  otherwise 
specified.  Many  of  the  techniques  developed,  however,  will  also  be  useful  for 
parallel  systems. 

The  usefulness  of  distributed  systems  has  spurred  a  significant  amount  of 
research  [Lampson  81,  Alford  85,  Raynal  88].  There  have  been  advances  both 
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Figure  1. 1:  The  Focus  of  this  Dissertation 
in  hard^^  are  and  software  but  the  design  of  distributed  software  has  proven  to 
be  more  difficult  than  that  of  distributed  hardware.  Architectures,  such  as 
Hypercube,  provide  up  to  16K  processors  connected  by  a  network.  The  exploi¬ 
tation  of  such  hardware  still  remains  a  challenging  task.  This  dissertation  deals 
only  with  techniques  for  the  design  of  distributed  software  though  many  tech¬ 
niques  developed  will  also  be  useful  for  designing  distributed  hardware. 

The  design  of  sound  distributed  systems  requires  formal  specification  and 
analysis  techniques.  Many  algorithms  informally  argued  to  be  correct,  reveal 
errors  in  later  analysis.  Formal  methods  would  eliminate  this  problem  by 
avoiding  any  ambiguity  that  arises  in  informal  reasoning.  Formal  specification 
also  lends  itself  to  automatic  analysis.  Figure  1.1  shows  the  focus  of  the 
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dissertation. 


1.  Issues  in  Modeling  Concurrent  Systems 

A  model  for  a  concurrent  system  would  have  different  characteristics  from 
models  used  in  a  different  domain  such  as  security.  For  example,  we  would 
expect  a  model  for  a  concurrent  system  to  have  features  for  expressing  com¬ 
munication  and  synchronization  among  multiple  entities.  In  this  section,  we 
summarize  the  issues  in  formal  specification  and  analysis  of  concurrent  sys¬ 
tems.  These  are  as  follows; 

1.1.  Processes:  Explicit  vs  Implicit 

As  defined  earlier,  a  c  mcurrent  system  has  more  than  one  process.  Some 
models  assume  that  processes  are  specified  explicitly  by  the  user.  Thus,  the 
user  is  responsible  for  specifying  what  should  be  done  by  who.  Alternatively, 
the  model  may  be  based  on  the  idea  of  implicit  parallelism.  Here  the  user  just 
specifies  what  needs  to  be  done  and  the  system  arranges  for  its  concurrent 
computation.  The  detection  of  parallelism  has  been  found  to  be  an  extremely 
hard  problem  and  therefore  we  have  chosen  to  use  explicit  specification  of  con¬ 
currency  in  our  model. 

1.2.  Communication:  Shared  Variable  vs  Messages 

If  multiple  processes  in  a  concurrent  system  need  to  coordinate,  they  must 
communicate  with  each  other.  This  communication  is  traditionally  expressed 
via  shared  variable  model  or  explicit  messages.  The  shared  variable  model 
assumes  that  a  process  can  write  into  a  shared  memory  location,  from  which 
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other  processes  can  read.  In  this  paradigm,  data  structures  are  shared  and  syn¬ 
chronization  is  required  to  ensure  that  accesses  and  updates  to  the  data  is 
proper.  Messages  is  an  alternative  form  of  communication  in  which  processes 
do  not  share  any  data.  A  process  has  to  explicitly  send  the  information 
required  by  some  other  process.  Lynch  and  Fischer  [Filman  84)  describe  some 
of  the  difficulties  of  shared  variable  communication: 

The  say  in  which  proceaaea  connunicate  with  other 
proceBBte  and  with  their  environnente  ia  by  scans  of 
variabLeo ...  Unlike  meaBage-based  conuunication  mechan- 
ieme,  there  is  no  guarantee  that  anyone  mill  ever  read 
the  value,  nor  is  there  any  primitive  mechanism  to  inform 
the  writer  that  the  value  haa  been  read.  Thus  for  sean- 
ingful  cossun teat  ion  to  take  place ,  both  parties  must 
adhere  to  previouely-agreed-upon-protocola  ..) 

\\'ith  the  above  in  mind,  we  have  assumed  that  communication  is  tia 
messages  in  our  model. 


1.3.  Buffering:  L  i. buffered  vs  Vnbounded  Buffering 

An  issue  that  is  important  for  message  based  systems  is  the  number  of 
messages  that  can  be  pending  at  any  time.  Some  systems  provide  unbuffered 
message^  or  synchronous  messages  which  must  be  received  by  the  receiver 
before  the  sender  of  the  message  can  proceed.  Other  systems  provide  buffered 
messages  or  ast  nchronous  messages  which  do  not  block  the  sender.  Note  that 
asynchronous  systems  can  use  either  synchronous  or  synchronous  message 
passing.  We  have  assumed  synchronous  message  passing  in  our  model.  Hoare 
gives  the  following  reasons  for  synchronized  communication.  (1)  Synchronized 
communication  is  more  basic  as  it  matches  closely  a  physical  realization  on 
wires  which  connect  processing  agents.  Such  wires  cannot  store  messages.  (2) 
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It  also  matches  closely  the  effect  of  calling  and  returning  from  subroutines 
within  a  single  processor,  copying  the  values  of  the  parameters  and  the  results. 
(3)  When  buffering  is  desired,  it  can  be  implemented  simply  as  a  process;  and 
the  degree  of  buffering  can  be  precisely  controlled  by  the  programmer.  (4)  The 
mathematical  treatment  of  systems  with  unbounded  buffering  is  also  compli¬ 
cated  by  the  fact  that  that  every  network  is  an  infinite  state  machine  even 
when  the  component  processes  are  finite.  (5)  Buffering  also  makes  fault 
recovery  difficult  as  the  failure  of  a  send  is  detected  much  later  in  the  pro¬ 
gram. 

1.4.  Expressive  Power:  Richness  vs  Tractability 

The  model  should  be  rich  enough  to  express  important  aspects  of  the  sys¬ 
tem.  For  example,  a  finite  state  machine  cannot  model  any  system  wliich  can 
have  an  unbounded  number  of  states,  and  may  therefore  be  unsuitable  to 
model  some  real  life  applications.  A  model  that  is  theoretically  more  powerful, 
however,  is  inherently  more  difficult  to  analyze.  For  example,  Turing 
machines,  the  most  general  model  of  computation  known,  are  unanalyzable  for 
most  interesting  problems,  such  as  baiting  and  equality.  Any  model  for  con¬ 
current  system  should  strike  a  good  compromise  between  its  expressive  power 
and  its  analyzability.  Our  model  is  equivalent  to  Petri  nets  which  are  not  only 
rich  enough  to  capture  unboundedness  but  also  simple  enough  to  guarantee 
that  the  halting  problem  is  decidable. 

Note  that,  even  if  two  models  have  the  same  expressive  power,  they  may 
have  different  expressive  convenience.  For  example,  Ada  and  Turing  machine 
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have  the  same  theoretical  power  but  it  is  much  more  difficult  to  write  pro¬ 
grams  in  Turing  machine  formalism  than  in  Ada.  Models  that  are  used  for 
proving  properties  about  a  system  tend  to  be  stripped  of  syntactic  conveni¬ 
ences,  while  models  that  are  used  as  implementation  tools  have  syntactic  sugar 
added  to  them. 

2.  Contributions  of  this  Report 

•  A  formal  model  for  concurrent  systems  called  the  Synchronous  Token 
based  Communicating  State(STOCS)  is  proposed.  To  prove  that  a 
STOCS  machine  is  amenable  to  net-theoretic  analysis,  we  prove  that  the 
reachability  problem  in  a  Petri  net  is  reducible  to  that  in  a  STOCS 
machine  and  vice-versa.  The  STOCS  model  is  easier  to  use  than  Petri 
nets,  as  it  supports  modularity  in  specification  and  analysis.  For  example, 
we  show  that  analysis  of  safety  properties  can  avoid  searching  global  state 
space,  by  considering  only  the  relevant  modules. 

•  W'e  show  that  the  STOCS  model  can  be  characterized  algebraically  by 
concurrent  regular  expressions.  Concurrent  regular  expressions  extend 
cl.Tssical  regular  expressions  with  three  operators  -  interleaving,  interleav¬ 
ing  closure  and  synchronous  composition.  Thus,  the  STOCS  model  com¬ 
bines  advantages  of  both  algebraic  and  net-theoretic  approaches. 

•  We  provide  a  unified  treatment  of  oracvlar  and  demonic  non-determinism 
in  the  STOCS  model.  We  provide  denotational  semantics  of  STOCS 
machines  and  concurrent  regular  expressions  which  can  take  internal 
actions. 
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•  Conventional  automatic  analysis  techniques  to  catch  logical  errors  in  a 
concurrent  system  may  be  infeasible  because  the  system  may  have  a  large, 
or  even  an  unknown  number  of  processes.  These  techniques,  which  are 
based  on  state  space  e.xploration,  run  into  the  state  explosion  problem. 
Since  most  distributed  systems  have  one  or  more  sets  of  identical 
processes,  we  exploit  the  symmetry  to  reduce  the  state  space  for 
automatic  analysis  techniques.  We  describe  symbolic  and  inductive  tech¬ 
niques  to  analyze  a  STOCS  machine. 

•  Present  concurrent  languages  do  not  support  any  form  of  analysis  of  the 
communication  structure  of  programs.  To  support  high  level  specification 
and  analysis  of  distributed  systems,  we  propose  two  new  constructs  based 
on  STOCS  formalism  -  handshake  and  unit.  The  handshake  construct  is 
a  remote  procedure  call  generalized  for  multiple  parties.  The  unit  con¬ 
struct  has  three  functions  -  to  restrict  the  possible  calls  to  various 
handshake  procedures,  to  provide  a  synchronization  mechanism,  and  to 
specify  computation  that  is  directly  relevant  to  communication.  These 
constructs  can  easily  be  added  to  any  e.xisting  language.  The  current  sys¬ 
tem  called  C'onC(Concurrent  C)  extends  ”C”  for  concurrent  program¬ 
ming.  A  prototype  cif  ConC  runs  on  a  Sun  cluster  operating  under  Unix 
4.2  BSD. 

•  Implementation  of  a  system  expressed  in  the  STOCS  model  requires  exe¬ 
cution  of  multi-process  shared  events.  We  present  a  fair  and  efficient  algo¬ 
rithm  for  execution  of  multi-process  shared  events.  We  also  present  its 
application  to  distributed  implementation  of  a  generalized  CSP 
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alternative  command.  We  show  that  our  solution  is  superior  to  proposed 
implementations  for  generalized  CSP  alternative  command. 

3.  Outline  of  the  Report 

Chapter  2  presents  an  overview  of  the  previous  work  in  modeling  and 
analysis  of  concurrent  systems.  Chapter  3  provides  the  definition  of  the 
STOCS  model.  It  also  presents  many  modeling  techniques  for  the  STOC'S 
model.  Chapter  4  describes  an  algebraic  characterization  of  a  STOCS  machine 
using  concurrent  regular  expressions.  Chapter  5  compares  the  STOCS  Model 
with  Petri  nets.  It  shows  by  a  constructive  proof  that  the  reachability  problem 
is  equivalent  for  STOCS  machines  and  Petri  nets.  It  compares  the  modeling 
convenience  in  Petri  nets  and  STOCS  machines.  Chapter  6  addresses  the  issue 
of  modeling  internal  actions  using  STOCS  machines  and  provides  denolational 
semantics  for  processes  modeled  using  concurrent  regular  expressions.  Chapter 
7  describes  projection,  symbolic  and  inductive  techniques  to  analyze  a  STOCS 
machine.  It  demonstrates  these  techniques  by  analyzing  several  examples:  2- 
out-of-3  problem,  readers  writers  problem,  the  dining  philosophers  problem 
and  the  mutual  exclusion  problem.  Chapter  8  describes  Concurrent  C  (ConC), 
a  programming  language  that  extends  C  with  constructs  from  the  STOCS 
model.  Chapter  9  presents  a  fair  algorithm  to  execute  multi-process  shared 
events. 

Following  is  the  list  of  acronyms  used  in  this  report. 
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Acronym 


Meaning 


STOCS 

Synchronous  Token  Based  Communicating  State 

FLSTOCS 

Free  Labeled  STOCS 

Deterministic  STOCS 

LSTOCS 

Uncontrollable  STOCS 

FSM 

Finite  State  Machine 

PN 

Petri  Net 

FLOPN 

Free  Labeled  Ordinary  PN 

RE 

Regular  Expression 

CRE 

Concurrent  Regular  Expression 

I'CRE 

L^ncontrollable  CRE 

ConC 

Concurrent  C 
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CHAPTER  2 


Previous  Work 

The  importance  of  concurrent  systems  has  resulted  in  extensive  research 
on  formal  models  for  expressing  concurrent  systems.  Models  capture  the 
essential  features  of  the  system.  In  this  chapter,  we  summarize  the  important 
models  that  have  been  developed  to  express  concurrent  systems.  We  evaluate 
these  models  for  their  suitability  in  modeling  concurrent  systems. 

1.  Petri  Nets 


Figure  2.1  Petri  Net  example 

Petri  nets,  first  developed  by  Petri  (Petri  62],  have  been  immensely  popu¬ 
lar  for  specifying  concurrent  systems.  A  general  Petri  net  (or  simply  a  Petri 
net)  is  a  directed  bipartite  multigraph.  There  are  two  kinds  of  nodes  -  places 
and  transitions  -  represented  by  circles  and  lines,  respectively.  An  example  is 
shown  in  figure  2.1.  It  has  five  places(pi-p5)  and  six  transitions(t|— /g).  All  arcs 
are  drawn  between  a  place  and  a  transition  or  a  transition  and  a  place.  There 
can  be  multiple  arcs  between  the  same  pair  of  nodes,  as  seen  between  t^  and 
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(A  Petri  net  which  has  only  simple  arcs  is  called  an  ordinary  Petri  net.  It 
is  just  a  graph  instead  of  a  multigraph.)  A  marking  of  a  Petri  Net  is  a  function 
which  associates  a  certain  finite  non-negative  number  of  “tokens”  with  each 
place  of  the  Petri  Net.  In  the  Petri  Net  shown  in  figure  2.1,  Pz  contains  one 
token  and  contains  2  tokens.  Arcs  from  places  to  a  transition  are  called 
input  arcs  to  the  transition.  Arcs  from  a  transition  to  places  are  called  output 
arcs  of  the  transition.  Transition  /5  has  two  input  arcs,  one  each  from  pj  and 
P4.  Transition  t4  has  3  output  arcs,  one  to  Pz  and  two  to  P4. 

Therefore,  a  Petri  net  PN  can  be  formally  represented  by  a  five-tuple  (P, 
T,  A/q,  I,  O),  where: 

•  P  is  the  set  of  places; 

•  T  is  the  set  of  transitions; 

•  A/q  is  the  initial  net  marking; 

•  I,  O:  T  -  >  P"  (the  power  set  of  P); 

•  I(t)  is  the  set  of  the  input  places  of  transition  t;  and 

•  0(t)  is  the  set  of  the  output  places  of  transition  t. 

A  transition  fires  by  removing  tokens  from  the  source  places  of  its  input 
arcs  and  puts  tokens  in  the  destination  places  of  its  output  arcs.  The  number 
of  tokens  removed  from  a  place  when  a  transition  fires  is  equal  to  the  number 
of  arcs  from  that  place  to  the  transition.  Similarly,  the  number  of  tokens 
added  to  a  place  as  a  result  of  the  firing  of  a  transition  is  equal  to  the  number 
of  arcs  from  the  transition  to  that  place.  The  number  of  tokens  in  any  place 
can  never  become  negative,  so  a  transition  can  fire  only  if  there  are  sufficient 
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number  of  tokens  at  the  source  places  of  all  its  input  arcs.  Such  a  transition  is 
called  “firable”.  In  the  Petri  Net  shown  in  Ggure  2.1,  transitions  (4  and  t3  are 
firable.  Transition  /3  can  fire  by  removing  one  token  from  P2  and  Since 
/3  has  no  output  arcs,  firing  (3  does  not  add  tokens  to  any  place.  If  transition 
t4  fires,  it  adds  2  tokens  to  p^.  The  number  of  tokens  in  po  remains  1,  since  f4 
puts  back  the  token  it  removes. 

Each  transition  of  a  Petri  Net  can  be  associated  with  a  label.  (In  the 
example  transitions  /  I— /6  have  labels  a-f  respectively.)  A  sequence  of  transi¬ 
tion  firings  would  be  represented  as  a  string  of  labels.  We  can  also  define  an 
acceptance  condition  for  the  Petri  Net.  All  configurations  of  the  Petri  Net 
satisfying  the  acceptance  condition  are  final  configurations.  If  a  sequence  of 
transition  firings  takes  the  Petri  Net  from  its  initial  configuration  to  a  final 
configuration,  the  string  formed  by  the  sequence  of  labels  of  the  transitions  is 
said  to  be  accepted  by  the  Petri  Net  The  set  of  all  possible  strings  accepted 
by  a  Petri  Net  is  called  the  language  of  the  Petri  Net.  Different  acceptance 
conditions  and  constraints  on  the  labeling  function  yield  different  types  of 
languages  (Peterson  81].  [Peterson  81,  Reisig  85,  Genrich  80]  provide  an  over¬ 
view  of  research  in  the  area  of  Petri  nets. 

2.  Calculus  of  Communicating  Systems  (CCS) 

The  Calculus  of  Communicating  Systems  developed  by  Milner  [Milner  80] 
had  a  profound  impact  on  the  science  of  specifying  synchronous  systems.  The 
goal  of  his  work  is  to  develop  a  formal  calculus  for  concurrent  computation, 
similar  to  the  way  lambda  calculus  is  a  formal  calculus  of  uniprocess  computa- 
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tion.  This  formalism  is  based  on  two  central  ideas  -  synchronized  communica¬ 
tion  and  observation  equivalence.  Each  concurrent  system  is  described  by 
means  of  algebraic  expressions  called  behavior  expressions.  The  calculus  pro¬ 
vides  laws  to  prove  the  equivalence  between  two  behavior  expressions 
Behavior  expressions  consist  of  multiple  agents  communicating  by  means  of 
synchronous  composition.  A  process  is  defined  by  the  following  syntax;  P 
a.Q  I  Q-l-R  I  NIL  1  r.Q  1  QIR  I  Q  I  Q[S]  The  semantics  of  behavior  expres¬ 
sions  is  (informally)  as  follows; 

t.Q;  Process  P  acts  as  Q  after  a  hidden  action 
a.Q;  Process  P  acts  as  Q  after  the  experiment 

Q-l-R;  Process  P  acts  either  as  Q  or  R  depending  upon  the  choice  offered 

NIL;  Process  P  does  not  admit  of  any  experiment 

QIR;  Process  P  act  as  composition  of  processes  Q  and  R 

Q....;  Process  P  acts  as  Q  with  label  a  hidden 

Q(S];  Process  P  acts  as  Q  with  the  relabeling  function  S. 

For  example,  a  binary  semaphore  s,  may  be  specified  as  s  =  PVs,  which 

requires  that  a  call  to  must  be  made  between  two  calls  to  P’s. 

CCS  has  been  applied  to  provide  semantics  of  programming  languages 
such  as  eSP  and  NIL.  Even  though  CCS  provides  an  elegant  formalism  for 
understanding  the  meaning  of  concurrent  systems,  it  is  not  useful  as  a 
specification  tool  for  real  systems.  General  CCS  is  Turing  -equivalent  and 
therefore  unanalyzable  for  most  properties. 


14 


3.  Communicating  Sequential  Processes  (CSP) 

CSP,  developed  by  Hoare[Hoare  85],  provides  a  distributed  language  with 
a  sound  mathematical  background.  A  CSP  program  is  a  static  set  of  explicit 
processes.  Pairs  of  processes  communicate  by  naming  each  other  in  input  and 
output  statements.  Thus,  if  A  wishes  to  receive  a  value  from  B  and  store  it  in 
the  variable  x,  it  will  execute  the  statement  B  ?  x  and  this  statement  will  block 
until  process  B  executes  an  output  statement  by  Alexp.  Thus,  communication 
is  synchronous  with  unidirectional  information  flow. 

Guarded  commands  are  used  to  introduce  indeterminacy.  A  guarded 
command  is  a  conditional  statement.  The  condition  of  the  clause  is  a  boolean 
expression.  Optionally,  it  may  have  an  input  or  output  statement.  For  exam¬ 
ple,  a  process  that  merges  characters  from  X,  Y  and  Z  and  passes  them  to  sink 
is  specified  in  CSP  as  follows: 

Merge::  c:  character; 

*[X?c  ->  Sinkic 

[] 

Y?c  ->  Sinkic 

[] 

Z?c  ->  Sinkic 

] 

The  name  of  the  process  is  Merge.  *  is  the  repetitive  operator  which  exe¬ 
cutes  a  command  repeatedly  until  all  the  guard  clauses  in  the  command  fail. 
X?c  is  an  input  command.  An  input/output  command  fails  if  the  process 
named  in  the  command  (X,  in  this  case)  has  terminated.  Sinkic  is  the  action 
which  is  executed  if  the  guard  is  true.  |]  provides  indeterminacy  and  the  pro¬ 
cess  may  choose  any  of  the  statements  if  more  than  one  process  is  ready  to 
communicate. 
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General  CSP  is  Turing-equivalent  and  therefore  cannot  be  analyzed 
automatically  for  most  properties. 

4.  Actor  Systems 

The  Actor  model  is  based  on  the  idea  of  object-oriented  computation. 
Th  is  model  was  developed  by  Carl  Hewitt  and  his  colleagues  at  M.I.T.  [Hewitt 
79].  The  discussion  below  is  summarized  from  [Filman  84).  In  an  Actor  sys¬ 
tem  everything  is  an  object  called  an  actor.  Actors  communicate  with  each 
other  by  sending  messages.  Thus  Actor  system  uses  non-synchronized  com¬ 
munication.  in  contrast  to  CCS.  There  are  three  kinds  of  actors;  primitive 
actors,  unserialized  actors,  and  serialized  actors.  Primitive  actors  correspond  to 
the  data  and  procedure  primitives  of  the  computer  system.  For  example,  2 
and  the  function  are  primitive  actors.  Serialized  actors  have  a  local  state 
that  the  actor  itself  can  change,  while  unserialized  actors  cannot  change  their 
local  state.  A  typical  unserialized  actor  is  factorial  which  can  be  imple¬ 
mented  in  terms  of  other  primitive  and  unserialized  actors.  A  serialized  actor 
associates  state  with  a  function.  Serialized  actors  process  messages  serially  - 
one  at  a  time. 

Every  actor  has  a  script  (program)  and  acquaintances  (data).  When  a 
message  arrives  at  an  actor,  the  actor’s  script  is  applied  to  that  message.  For 
example,  an  unserialized  actor  may  accept  messages  like  "add  yourself  to  3, 
and  send  the  answer  to  actor  00042". 

The  Actor  metaphor  provides  uniform,  independent  entities  that  com¬ 
municate  with  each  other  by  message  passing.  Actor  model  thus  provides  a 
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powerful  formalism  for  expressing  concurrent  computation.  No  structure  over 
waiting  messages  (e.g.  ordering  by  send-time),  and  dynamic  creation  of  actors 
poses  difficulties  for  a  tractable  extensional  theory  of  Actor  Models  [Milner  80]. 

5.  Path  Expressions 

Path  expressions  were  first  defined  by  Campbell  and  Habermann  [Camp¬ 
bell  74]  as  a  synchronization  mechanism.  Using  path  expressions,  a  program¬ 
mer  can  specify  all  constraints  on  the  execution  of  operations.  Code  to  enforce 
these  constraints  is  generated  by  the  compiler.  The  syntax  of  a  path  expression 
is; 

path  path. list  end 

A  path. list  contains  operation  names  and  path  operators.  Path  operators 
include  for  concurrency.  for  sequencing  n.(path. list)  to  specify  up  to  n 
concurrent  activations  of  path. list,  and  ’’[path. list]”  to  specify  an  unbounded 
number  of  concurrent  activations  of  path.  list.  For  example, 

path  deposit,  fetch  end 

places  no  constraints  on  the  execution  of  deposit  and  fetch, 
path  deposit;  fetch  end 

specifies  that  each  fetch  be  preceded  by  an  activation  of  a  deposit.  Synchroni¬ 
zation  constraints  for  a  bounded  buffer  of  size  N  are  specified  by 

path  N:(l:(deposit);  l;(fetch))  end 

This  mechanism  was  incorporated  in  Path  Pascal.  One  of  the  main  prob¬ 
lems  path  expressions  have  is  that  it  is  difficult  to  include  synchronization  con- 


17 


straints  that  depend  on  the  state  of  the  resources. 

Another  formalism  called  COSY  (Concurrent  System)  [Lauer  79]  vas 
inspired  by  path  expressions.  A  path  expression,  referred  to  as  a  GR-path,  is 
defined  as  follows:  A  GR-path  is  a  string  P=P^P2-.Pn  where  each  P,-  is  an  R- 
path.  An  R-path  is  a  sequential  constraint  on  the  system  expressed  as  a  regular 
expression.  Informally,  if  we  think  of  P,-  as  describing  the  constraint  c,-  then 
the  GR-path  P  describes  a  constraint  C|  and  and  ..c„. 

It  can  be  easily  observed  that  since  each  R-path  is  a  regular  expression,  a 
GR-path  is  just  an  intersection  of  regular  expressions.  In  other  words,  a  GR- 
path  can  model  only  a  finite  stale  system. 

6.  S/R  Model 

The  S/R  model  is  a  state  machine  approach  to  specification  and  analysis 
[.Aggnrwal  S7j.  An  S/R  system  consists  of  one  of  more  processes.  A  process  P 
is  defined  over  a  boolean  algebra  L  as  a  five-tuple  P  =  (\',  S,  tr,  M,  1)  where: 

•  is  a  set  of  states  of  P 

•  S  is  the  set  of  selections  of  P.  S  C  L 

•  <T  is  the  selector  function  of  P,  aX-*2 

•  M  is  the  transition  matrix  of  P,  A/;Vx  V— ♦// 

•  I  is  the  initial  slate  of  P,  leV. 

The  selector  function  associates  with  each  state  s  the  set  of  possible  selec¬ 
tions  a(s)  that  can  be  made  from  state  s.  In  our  description,  the  selections 
will  appear  in  curly  brackets  next  to  the  state.  The  transition  matrix  is  like  an 
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adjacency  matrix  of  a  directed  graph  with  vertices  V  where  the  nonzero  enti¬ 
ties  are  actual  labels  describing  the  conditions  for  a  transition  to  be  enabled. 
Given  an  edge  label  l=-M{v,tv)  from  state  v  to  u',  if  the  selection  of  a  process 
is  s  in  state  r.  then  s.l^O  means  that  the  transition  to  u>  is  possible.  One  can 
define  a  "calculus”  of  the  processes  so  that  the  product  of  a  process  is  again  a 
process.  Given  processes  F,,..,Pn  with  P,=(r,,5,,(T,,A/,./,),  the  product  of 

fi 

these  processes  is  defined  as  P  =  P^=(V,S ,o,M ,1)  where: 

t«=i 

•  v=  X  r. 

t-=i 

•  p,  -S- 

t-=i 

f) 

•  <7=  p, 

1=1 

n 

.  /=  X  /, 

1  =  I 

For  example,  consider  two  individual  processes  A  and  B  that  do  not  wish 
to  be  in  the  same  room  of  a  two  room  house  consisting  of  an  ATTIC  and  a 
CELLAR.  .A  and  B  can  choose  to  move  from  one  room  to  the  other  (indicated 
by  selections  IT,  DOWN)  subject  to  the  constraint  that  an  individual  in  a 
room  desiring  to  remain  in  the  room  has  priority.  The  coordination  between 
A  and  B  can  be  shown  as  in  Figure  2.2.  In  order  to  shov  that  A  and  B  are 
never  both  together,  starting  from  the  initial  state  A  in  ATTIC,  B  in  CEL¬ 
LAR,  the  product  of  A  and  B  is  computed.  The  resulting  process  is  shown  in 
Figure  2.3  in  which  only  the  states  (ATTIC,  CELLAR)  and  (CELL.AR, 
ATTIC)  are  reachable. 
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Process  A 

l(A:n=)+(A:DO\VN)*(B;DOWN)l 


Process  B 


|(B;UP)+(B;DO\VN)*(A:DO\VN)l 

Q 

ATTIC  {ITP,  DOWN}  VT  ATTIC  {UP,  DOWN} 

A 

l(A;DOWN)  I  \  l(B:DOWN) 


](B:DOWN)  )  KA.DOWN)  -  .  - 

•,A:UP)|  V  /  I  I 

CELLAR  (IT.  DOWN}  CELLAR  {IT,  DOWN} 


((A  DOWN)-(.(A:UP)*(B:UP)l 

Process  P* 

(A:IT)- 
\  I  (B;DO\VN) 

ATTIC  ^  CELLAR 


|(B;DOWN)+(B:UP)*{A;lT}] 


(A:UP)*  / 
(BDOWN) 


(A:DOWN) 

*(B;UP) 


\ 


o  cellar  S  attic 

(A  DOWN) 

•(B.VP) 


Figure  2.2:  An  example  of  S/R  model 
Since  an  S/R  process  has  a  6nite  number  of  states  and  a  finite  number  of 
selections,  an  S/R  process  is  theoretically  equivalent  to  a  finite  state  machine. 
I'he  ability  to  label  an  edge  with  any  boolean  formula  leads  to  a  concise 
representation  of  man)  problems.  This  feature,  however,  also  makes  it  difficult 
to  provide  an  algebraic  characterization  of  sequences  of  selections  made  by  a 
S/R  system.  In  addition,  the  system  executes  in  two  phases  -  selection  and 
resolution.  All  processes  make  their  local  selections  and  then  the  global  resolu¬ 
tion  is  done.  This  paradigm  may  not  be  appropriate  for  specifying  an  asyn¬ 
chronous  system  with  more  than  two  processes. 
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7.  Other  Systems 


Many  other  concurrent  models  have  been  developed  for  concurrent  pro¬ 
gramming.  Among  \'on  Neuman  languages  are  Ada  [Ada  83],  SR  [Andrews 
82],  Occam  [IXMOS  84],  PUTS  [Feldman  79],  Concurrent  Pascal  [Brinch  Han¬ 
sen  75],  Concurrent  C  [Gehani  84]  and  Distributed  Processes  [Brinch  Hansen 
78].  In  addition,  there  are  data-flow  languages  [Ackerman  82]  such  as  \’^AL, 
and  applicative  languges  such  as  FP  [Backus  78].  Since  in  this  thesis  we  focus 
on  automatically  analyzable  models,  none  of  these  models  suits  our  purpose. 

Many  models  have  been  proposed  to  study  the  semantics  of  concurrency 
and  nondeterminacy.  Some  of  these  are  Nivat’s  transition  systems  [Nivat  82], 
Winskel's  event  structures  [Winskel  82],  Pratt’s  pomsets  [Pratt  82],  Kahn’s 
model  [Kahn  77],  Concurrent  Transition  Systems  [Stark  87]  and  input/output 
automata  [Steenstrup  83].  These  models  are  useful  for  understanding  semantics 
of  concurrency,  but  their  usefulness  as  specification  tools  remain  to  be  seen. 

8.  Conclusions 

All  the  above  models  have  some  good  ideas  and  are  suitable  for  some 
applications  but  the  diversity  shows  us  that  there  is  no  consensus  about  the 
right  way  of  modeling  concurrent  systems.  For  implementation  of  concurrent 
systems,  a  model  should  have  Turing-equivalent  power  so  that  all  partial 
recursive  functions  are  expressible.  Thus  we  believe  that  Petri  nets,  finite  state 
automata  and  derived  models  such  as  S/R  model  and  Path  expressions  are 
inadequate  for  concurrent  programming.  Ada,  CCS,  and  CSP  are  more  suit¬ 
able  for  concurrent  programming  with  synchronous  messages,  whereas  Actors 
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and  PLITS  (Feldman  79]  are  more  suitable  for  programming  with  asynchro¬ 
nous  messages.  Programs  written  in  such  languages  can  be  proven  correct 
only  manually. 

Before  the  actual  implementation  of  the  concurrent  system,  it  is  desirable 
to  specify  the  crucial  features  of  the  system  in  some  simple  model  which  can 
be  analyzed  automatically.  Petri  net,  COSY  and  S/R  can  be  useful  at  this 
ph  ase  of  software  development.  Petri  nets  have  the  advantage  of  being  able  to 
model  unbounded  number  of  states  impossible  to  model  in  COSY  and  S/R. 
Petri  nets,  however,  get  very  complex  with  an  increase  in  the  number  of 
processes.  This  is  because  Petri  nets  do  not  support  modularity  for  specifying 
concurrent  systems  with  synchronous  communication.  COSY  and  S/R  support 
modularity  for  synchronous  communication  and  thus  there  is  a  need  for  a 
Petri  net  equivalent  model  with  the  modularity  of  COSY  and  S/R.  The 
STOCS  model,  we  believe,  fills  this  need. 
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CHAPTER  3 


The  STOCS  Model  -  Basic  Definitions 


1.  Introduction 

Concurrent  languages  such  as  Ada  (Ada  83),  CSP  (Hoare  85]  and  Argus 
[Liskov  84]  have  good  expressive  power  but  any  system  that  is  specified  using 
these  languages  can  only  be  analyzed  manually.  As  concurrent  systems  are 
difficult  to  design,  the  simplest  of  them  can  have  subtle  errors.  To  avoid  these 
errors,  we  need  to  capture  essential  aspects  of  the  system  in  a  model  and  then 
analyze  it  for  correctness.  Models  for  concurrent  systems  that  can  be  analyzed 
automatically  have  less  expressive  power  than  programming  languages.  They 
can  be  categorized  roughly  into  two  groups:  algebra  based  and  transitioii 
based  models. 

The  algebra  based  models  specify  all  possible  traces  of  concurrent  systems 
by  means  of  algebraic  operations  on  sets  of  traces.  Examples  of  such  models 
are  path  expressions  [Lauer  75],  behavior  expressions  [Milner  80]  and  extended 
regular  expressions.  Examples  of  tools  to  analyze  the  specifications  based  on 
such  models  are  Path  Pascal  (Campbell  79],  CCS  (Milner  80]  and  Paisley  (Zave 
85].  Some  of  the  commonly  asked  questions  in  such  formal  systems  are:  Is  s  a 
possible  trace  of  the  concurrent  system  under  analysis?  Is  5j.  a  concurrent  sys¬ 
tem,  the  same  as  the  concurrent  system  ^2? 

The  transition  based  models  provide  a  computational  model  in  which  the 
behavior  of  the  system  is  generally  modeled  as  a  configuration  of  an  automa¬ 
ton.  Examples  of  the  transition  oriented  models  are  finite  state  machines 
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[Hopcroft  79],  S/R  Model  [Aggarwal  87],  UCLA  graphs  [Cerf  72],  and  Petri 
nets  [Reisig  85].  Examples  of  modeling  and  analysis  tools  based  on  these 
models  are  Spanner  (Aggarwal  87],  Affirm  [Gerhart  80]  and  PROTEL\N  [Bil- 
lingtpn  88]. 

In  th  is  chapter,  we  present  a  transition  based  model  called  the  Synchro¬ 
nous  TOken  based  Communicating  State(STOCS)  model.  This  chapter  is 
organized  as  follows.  Section  2  presents  the  STOCS  model  and  many  examples 
that  can  be  modeled  as  STOCS  machines.  Section  3  describes  a  STOCS 
machine  as  a  generalization  of  a  finite  state  machine.  Section  4  treats  a 
STOCS  machine  as  an  acceptor  of  strings  and  describes  its  language.  Section  5 
describes  deterministic  STOCS  machines  which  can  be  easily  simulated  to 
chfc  k  for  acceptance  of  a  string.  Section  6  describes  the  semantics  of  a 
STOCS  machine  by  defining  its  language.  Section  7  presents  some  paradigms 
for  modeling  by  the  STOCS  model. 

2.  Synchronous  Token  based  Communicating  State(STOCS)  Model 

Informally,  the  STCCS  model  has  five  concepts  -  vnit,  place,  token,  *~ 
place  and  synchronous  handshake.  A  STOCS  machine  consists  of  one  or 
more  units.  A  unit  is  used  to  model  a  single  process  or  a  set  of  non¬ 
interacting  processes.  Each  unit  is  an  extended  version  of  a  finite  state 
machine  consisting  of  places  and  arcs  between  them.  Tokens  are  used  to 
model  processes  or  data  items.  A  *-place  models  an  unbounded  number  of 
processes  or  data  items.  Synchronous  handshake  is  used  for  modeling  interac¬ 
tion  between  processes.  All  executions  in  a  STOCS  machine  take  place  in  a 
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synchronous  manner. 

Formally,  a  STOCS  machine  M  is  a  set  of  units  [Ui,U2,  -,U„)  where  each 

unit  is  a  five-tuple,  i.e.  where; 

•  P,  is  a  finite  set  of  places, 

•  C\  is  an  initial  configuration  which  is  a  function  from  the  set  of  places  to 
natural  numbers  fs'  and  a  special  symbol  i.e.  C,:P,— ♦(1NU{  *})■  This 
function  represents  the  concept  of  tokens  which  may  be  thought  of  as 
residing  in  places.  The  symbol  represents  an  infinite  number  of  tokens. 
The  place  which  has  *  tokens  is  called  a  *-ptace.  Other  places  are  called 
simple  places. 

•  li,  is  a  finite  set  of  handshake  labels 

•  (^,cp,  xi:,u{<}xP,-. 

•  P,  is  a  set  of  final  places,  F^QPi. 

The  configuration  of  a  STOCS  machine  can  change  by  the  following 

handshake  rules  (execution  rules). 

(1)  A  handshake  with  label  a  is  said  to  be  enabled  if  for  all  units 
(',=(P,-,C',,i;,,^,,P,)  such  that  oeS,-  there  exists  a  transition  (Pk,o,Pi)^^i 
with  C',(pi.)>l.  Informally,  a  handshake  occurs  simultaneously  in  all  units 
which  have  that  handshake  in  their  handshake  sets.  Thus  in  example  3.1, 
Figure  3.1,  req  is  enabled  only  if  both  P2  and  pg  have  tokens. 

(2)  A  handshake  a  may  take  place  if  it  is  enabled.  This  will  result  in  a  new 
marking  C\  for  all  participating  units,  and  is  defined  by 
<yM)=c\{p,)-i 
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C*,(p,)=C,(p,)+l. 

A  *-place  remains  the  same  after  addition  or  deletion  of  tokens.  Figure 
3.1  also  shows  the  configuration  of  M  after  the  execution  of  handshakes 
j)re  and  req. 

(3)  If  multiple  handshakes  are  enabled,  then  any  one  of  them  can  execute. 
For  example  in  Figure  3.1(b)  either  pre  or  crit  can  fire.  If  a  handshake  is 
enabled  in  such  a  manner  that  it  can  fire  in  multiple  ways,  then  the 
machine  chooses  the  way  in  an  oracular  manner.  This  is  analogous  to  a 
non-deterministic  finite  state  machine  accepting  a  symbol  that  is  labeled 
on  multiple  out*going  arcs. 

Example  3.1  :  Mutual  Exclusion  Problem 

As  an  example  of  a  STOCS  machine,  consider  the  mutual  exclusion  prob¬ 
lem.  where  at  most  one  process  can  execute  the  critical  region.  Each  process 
does  some  pre-critical  section  processing,  requests  the  permission  to  enter  criti¬ 
cal  section,  executes  critical  section,  releases  critical  section,  and  then  does 
some  post-critical  section  processing.  No  two  processes  can  be  allowed  to  be  in 
the  critical  section  at  the  same  time.  A  centralized  solution  can  be  expressed 
using  a  STOCS  machine  M  as  follows.  M  consists  of  two  units,  i.e.  M=[Ui,V2) 
where: 

Lr2={P2X2^Cnj2.F2) 

Pl={Pi-P2>Pi^P4  Ph)^  ^2=(P6.P7) 

^^={pre , req , crit ,rel ,post),  E2=(req,re/) 
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C',=(^0, 0,0,0),  C2=(1.0) 

f>\  =  {[PvVre:V2)AP2'^^(i,V\UPz^crit,p^),{p^,rel,p^)\p-^,j>ost,Px)} 

<52={(P6•»■C<7-P7)^(P7•»‘«^P6)} 

^l={Pl}.'f'2={p6P7} 


Pi 


I  execution 

Pi 


Figure  3.1;  A  STOCS  machine  for  Mutual  Exclusion 

f'l  corresponds  to  any  arbitrarily  large  number  of  processes  that  may  be 
interested  in  executing  the  critical  region.  A  process  can  execute  pre 
handshake  whenever  it  wants  as  pre  does  not  require  any  coordination.  Execu¬ 
tion  of  req,  however,  requires  participation  of  the  coordinator  process,  which  is 
possible  only  if  the  token  is  in  Pe-  ^^2  corresponds  to  a  critical  region  server 
which  grants  the  permission  needed  to  enter  the  critical  region.  A  token  in  p; 
indicates  that  some  process  is  executing  the  critical  region. 

The  graphical  representation  of  the  STOCS  machine  for  mutual  exclusion 
is  shown  in  Figure  3.1.  Each  place  is  represented  by  a  circle,  and  each  element 
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of  b  corresponds  to  a  directed  arc  between  a  pair  of  circles.  The  initial 
configuration  (alternatively  called  marking)  is  represented  by  placing  the 
appropriate  number  of  tokens  in  each  circle.  The  number  and  position  of 
tokens  may  change  during  eiecution. 

Example  3.2:  Producer  Consumer  Problem 

This  problem  concerns  shared  data.  The  producer  produces  items  which 
are  kept  in  a  buffer.  The  consumer  takes  these  items  from  the  buffer  and  con¬ 
sumes  them.  The  solution  requires  that  the  consumer  wait  if  no  item  exists  in 
the  buffer.  A  slight  variant  of  this  problem  assumes  that  the  buffer  is  bounded 
by  n.  The  solution  to  both  problems  expressed  in  the  STOCS  model  is  given  in 
Figure  3.2. 


put_item' 


S3 


u. 


put  {fern 


get  _  item 


i'3 

So 

get, item 


Consumer 


U3 

S5 

get,  item 


Figure  3.2:  A  STOCS  Machine  for  Producer  Consumer  Problem 

For  both  the  problems,  the  consumer  can  execute  get,  item  only  if  there  is 
a  token  in  the  place  p^.  If  the  buffer  is  unbounded,  the  producer  never  has  to 
wait,  whereas  if  the  buffer  is  bounded,  the  producer  may  have  to  wait  for  the 
buffer  to  become  empty  (that  is,  for  a  token  to  be  present  at  the  place  p^  of 
the  buffer).  Thus,  the  number  of  tokens  in  the  place  p^  represents  the  number 
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of  available  buffers  and  the  number  of  tokens  in  the  place  P4  represents  the 
number  of  filled  buffers.  Note  how  the  *-place  is  used  to  represent  an 
unbounded  number  of  available  buffers. 

Example  3.3:  2-out-or-3  Memory  Problem 

The  2-oul-of-3  problem  is  a  good  abstraction  for  many  resource  conten¬ 
tion  problems.  Assume  that  a  memory  scheduler  has  three  memory  blocks  and 
that  any  process  requires  two  memory  blocks  to  execute.  The  solution  for  a 
system  with  two  processes  is  given  in  Figure  3.3.  We  place  two  token  in  the 
place  Sj  to  signify  two  processes  and  three  tokens  in  the  place  S5  to  signify 
availability  of  three  memory  blocks.  This  example  illustrates  how  multiple 
tokens  can  be  used  to  represent  multiple  identical  processes  or  multiple  identi¬ 
cal  passive  resources  such  as  memory  blocks. 


Figure  3.3:  A  STOCS  Machine  for  2-out-of-3  problem 
3.  Relationship  of  STOCS  machines  with  Finite  State  Machines 

In  this  section,  we  describe  the  STOCS  machines  in  greater  details  by 
comparing  its  features  with  that  of  finite  state  machines. 

(1)  Current  State  vs  Current  Configuration 

There  is  no  concept  of  a  current  state  in  a  STOCS  machine,  as  there  is  in 
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a  finite  slate  machine.  Tokens  are  associated  with  places  and  can  be  thought  of 
as  residing  in  the  places.  A  transition  arc  is  said  to  be  enabled  when  its  tail 
has  at  least  one  token.  A  transition  occurs  by  moving  one  token  from  its  tail 
to  its  head.  All  tokens  are  identical  and  if  there  is  more  than  one  token  in  the 
tail,  any  one  of  the  tokens  may  be  moved.  This  has  the  advantage  of  ease  in 
representing  multiple  resources,  which  may  be  active,  such  as  processes,  or 
passive,  such  as  memory  blocks.  A  configuration  of  a  STOCS  machine  is  a 
specification  of  the  number  of  tokens  in  each  place  within  each  unit.  The 
number  of  tokens  in  a  place  can  be  any  finite  positive  number  or  a  special 
symbol  -  *.  The  symbol  *  is  used  to  represent  an  infinite  number  of  tokens.  If 
the  number  of  tokens  in  a  place  is  it  will  always  be  since  we  can  add  or 
subtract  any  finite  number  from  infinity.  These  places  are  useful  for  modeling 
unbounded  variables  as  in  Example  3.2  and  to  model  forks  and  joins  as  shown 
in  Figure  3.4. 


Parent  Process 


Figure  3.4:  Modeling  of  fork  and  join  in  the  STOCS  Model 
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{2}  Labeling  of  Transitions 


As  in  finite  state  machines,  each  transition  is  given  a  label.  All  labels  are 
derived  from  a  finite  set  of  symbols,  E,  the  handshake  set  of  the  STOCS 
machine.  If  two  or  more  units  have  transitions  labeled  with  the  same  symbol, 
then  these  transitions  must  occur  simultaneously,  i.e.  all  these  units  must  make 
the  transition.  This  is  the  only  form  of  interaction  among  the  units. 

(3)  PoiL'cr  of  a  unit  vs  Power  of  a  Finite  State  Machine 

If  a  unit  does  not  have  any  *-places  then  the  number  of  tokens  within  the 
unit  will  be  fixed  since  transitions  only  move  tokens  from  one  place  to  another. 
We  can  think  of  such  a  unit  as  a  number  of  identical  FSMs  operating  in  paral¬ 
lel.  Each  FSM  has  the  same  set  of  states  and  transitions  as  the  unit.  Each 
token  represents  the  current  place  of  one  FSM.  When  the  unit  makes  a  transi¬ 
tion,  moving  one  token  from,  say,  place  A  to  place  B  -  one  FSM  with  its 
current  place  A  makes  a  transition  to  place  B.  Since  all  FSMs  corresponding 
to  a  unit  are  identical,  it  does  not  matter  which  one  of  them  makes  the  transi¬ 
tion.  A  finite  number  of  identical  FSMs  can  be  simulated  by  a  single  FSM 
therefore,  a  unit  with  no  *-places  is  no  more  powerful  than  an  FSM  since  the 
number  of  states  is  finite.  In  fact,  a  unit  with  n  places  and  rn  tokens  can  be 
converted  into  an  FSM  with  no  more  than  n”*  states. 

‘-places  give  a  unit  more  power.  We  can  count  up  to  arbitrarily  large 
numbers  using  ‘-places.  But  within  a  unit,  multiple  ‘-places  do  not  yield  any 
additional  power.  If  there  is  more  than  one  ‘-place  in  a  unit,  we  can  merge  all 
of  them  into  one  ‘-place.  All  transitions  entering  or  leaving  any  of  the  original 
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*-places  will  now  enter  or  leave  the  new  *-place,  because  *  represents  infinity 
and  no  record  can  be  kept  of  the  number  of  tokens  that  have  entered  or  left 
the  state. 

Connectivity  of  the  Graph 

Note  that  unlike  FSMs  a  unit  need  not  necessarily  be  a  single  connected 
graph.  If  an  FSM  consists  of  more  than  one  connected  component,  all  com¬ 
ponents  which  do  not  contain  the  initial  state  can  be  deleted  since  these  states 
are  unreachable.  In  a  unit  we  can  have  multiple  components  and  each  of  these 
components  can  have  tokens  which  move  about  within  them.  Movement  of 
tokens  within  different  components  of  the  same  unit  is  completely  independent 
and  need  not  synchronize  with  each  other.  However,  tokens  moving  in 
different  units  must  interact. 

4.  The  Language  of  a  STOCS  Machine 

In  this  section,  we  treat  a  STOCS  machine  as  an  acceptor  of  strings.  We 
define  the  language  of  a  STOCS  machine  and  provide  the  motivation  of  its 
use.  We  also  show  that  a  class  of  STOCS  machines  called  deterministic 
STOCS  machines  is  particularly  easy  to  use  as  acceptors  of  strings. 

To  use  a  STOCS  machine  as  an  acceptor  of  strings  we  need  to  define  a 
certain  initial  configuration  and  a  set  of  final  configurations.  A  string  is 
accepted  if  the  STOCS  machine  starts  from  the  initial  configuration  and 
arrives  at  one  of  the  final  configurations  after  making  the  transitions 
corresponding  to  the  symbols  in  the  string.  (Obviously  the  string  must  be  over 
the  alphabet  D).  Instead  of  specifying  the  set  of  final  configurations  by 


eiinumerating  them  we  extend  the  definition  of  acceptance  from  finite  state 
machines.  We  define  a  set  of  final  places  in  each  unit. 

Definition:  A  configuration  of  a  STOCS  machine  is  a  final  configuration  if 
tliere  are  no  tokens  in  any  non-final  place. (i.e.,  all  tokens  in  all  units  are  in 
final  places).  By  definition,  all  *-places  are  final  places  since  the  number  of 
tokens  in  a  ‘-place  can  never  go  to  zero.t 
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Figure  3.5:  A  STOCS  machine  accepting  o”c6'’ 

C'onsider  the  example  shown  in  Figure  3.5.  This  STOCS  machine  consists 
of  two  units  and  its  is  alphabet  E  =  {  a,b,c  }.  The  first  unit  is  formed  by  the 
places  p,  and  po.  pj  is  a  ‘-place,  and  the  other  unit  consists  of  places  and 
p^.  Initially  there  is  one  token  in  place  P3.  The  final  places  of  the  system  are 
Pi  (since  it  is  a  ‘-place)  and  p^.  Since  symbols  a  and  6  are  shared  between  the 
two  units,  transitions  on  a  and  6  must  be  synchronized.  The  symbol  c  is  not 
present  in  the  first  unit  and  can  occur  any  time  its  transition  is  enabled  in  the 
second  unit. 

t  If  we  allow  ’-places  to  be  non-final  places,  then  no  string  will  be  accepted  by  a  STOCS 
machine. 
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This  STOCS  machine  accepts  the  language  {  i  n>0  }.  After  o” 

has  been  accepted,  there  will  be  n  tokens  in  place  P2-  The  conOguration  of 
unit  2  will  be  identical  to  its  initial  configuration.  On  accepting  c,  the  token  in 
unit  2  will  move  to  p^.  On  each  6,  one  token  will  be  removed  from  P2-  When 
the  number  of  6’s  becomes  equal  to  the  number  of  a’s  seen  earlier,  po  will 
become  empty.  This  is  an  ’accept’  configuration  because  places  P2  and  p^  will 
have  no  tokens.  Note  that  unit  2  ensures  that  the  string  accepted  is  of  the 
form  a  cb*  while  unit  1  ensures  that  ^a=ifb.  One  of  the  strengths  of  the 
.STOCS  model  is  its  ability  to  use  different  units  to  model  conceptually 
different  properties  of  a  language. 

Definition;  The  language  of  a  STOCS  machine  is  defined  as  the  set  of  all 
strings  that  are  possible  sequences  of  handshakes  from  the  initial 
configurations  to  an  accepting  configuration. 

For  example,  the  language  of  the  STOCS  machine  in  Figure  3.G  is 
1  V  >0}.  The  motivation  for  the  use  of  languages  comes  from  the  follow¬ 
ing; 

1.  Analysis;  The  language  of  a  STOCS  machine  characterizes  all  sequences  of 
actions  that  are  possible  in  the  system.  A  large  class  of  interesting  questions 
can  be  posed  in  language-theoretic  terms.  Some  of  these  questions  are:  Is  s  a 
member  of  the  language  L,  i.e.  is  the  following  string  of  computation  feasible  ? 
Is  there  a  string  that  satisfies  the  temporal  logic  formula  T?  Is  there  a  string 
which  contains  s  as  its  substring  ? 

2.  Characterization  The  language  of  the  STOCS  model  provide  us  with  a 
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Figure  3.6:  A  STOCS  machine  accepting 
^\  ay  of  specifying  the  behavior  of  a  STOC.S  machine  and  we  may  chose  to  con¬ 
sider  two  machines  equivalent  if  their  languages  are  identical.  Such  a  charac¬ 
terization  gives  us  a  chance  to  optimize  a  STOCS  machine.  Given  a  STOCS 
machine,  one  can  reduce  it  to  another  STOCS  machine  by  means  of  language 
preserving  transformations.  The  new  STOCS  machine  may  be  more  desirable 
because  it  has  less  places,  less  units  or  more  concurrency. 

3.  Synthesis  of  STOCS  Machines:  As  we  will  see  in  Chapter  4,  we  can 
synthesize  a  STOCS  machine  given  its  specification  in  terms  of  concurrent  reg¬ 
ular  expressions  which  are  algebraic  expressions  on  sets  of  strings.  In  general, 
given  any  form  of  specification  of  the  language  of  a  system,  it  is  useful  to  gen¬ 
erate  a  STOCS  machine  that  accepts  it. 

5 .  Deterministic  STOCS  (DSTOCS)  Machines 

To  check  the  acceptance  of  a  string  in  a  finite  state  machine,  we  simulate 
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the  machine  on  the  string.  If  it  is  deterministic,  we  need  only  keep  track  of  one 
current  state  during  the  simulation.  If  it  is  non-deterministic,  we  need  to 
examine  many  possible  paths  or  equivalently  keep  track  of  a  set  of  possible 
current  states.  A  sufficient  condition  for  a  finite  state  machine  to  be  deter¬ 
ministic  is  that  all  arcs  leaving  a  particular  state  have  distinct  labels  and  that 
there  be  no  arcs  labeled  c. 

A  STOCS  machine  is  deterministic  if,  when  simulating  a  string  we  need 
to  keep  track  of  only  one  "current  configuration”.  This  means  that  in  any 
reachable  configuration  accepting  a  particular  symbol  leads  to  only  one  possi¬ 
ble  next  configuration.  With  this  motivation,  we  define  a  deterministic  STOCS 
(DSTOCS)  machine  as  a  STOCS  machine  such  that 

(1)  If  a  unit  has  exactly  a  single  token  then  all  arcs  leaving  a  particular  place 
have  distinct  labels  and  there  are  no  arcs  labeled  e.  Such  a  unit  is  equivalent 
to  a  deterministic  finite  state  machine. 

(2)  If  a  unit  has  multiple  tokens,  then  it  must  be  free-labeled.  A  unit  is  free- 
labeled  if  it  has  distinct  labels  on  all  of  its  arcs  and  there  are  no  arcs  labeled  f. 

Simulation  of  a  D^^OCS  machine  requires  remembering  only  a  single 
configuration  because  on  a  given  symbol  a  unit  with  a  single  token  can  move 
to  only  one  possible  place  and  a  unit  with  multiple  tokens  has  only  one  arc 
labeled  with  it.  The  STOCS  machine  in  Figure  3.6  is  deterministic  because 
unit  2  has  a  single  token  and  it  satisfies  our  condition  for  units  with  single 
token,  while  unit  1  is  free  labeled. 

Note  that  units  with  single  tokens  are  essentially  finite  state  machines  and 
are  therefore  good  for  putting  regular  constraints  on  the  language.  Such  units 
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are,  however,  not  good  for  counting  which  is  done  by  units  which  are  free- 
labeled.  A  STOCS  machine  which  consists  of  only  free-labeled  units  is  called  a 
Free  Labeled  STOCS  (FLSTOCS)  machine,  (terminology  borrowed  from  Petri 
Net  theory). 

The  STOCS  machine  in  Figure  3.5  is  a  FLSTOCS  machine  because  each 
arc  in  every  unit  has  a  unique  label.  The  STOCS  machine  in  Figure  3.6  is  not 
an  FLSTOCS  machine  because  unit  2  has  two  arcs  labeled  6.  FLSTOCS 
machines  are  good  only  for  counting  and  may  not  even  accept  finite  languages. 
We  show  that  there  can  be  no  FLSTOCS  machine  accepting 
P  =  {€,0  ,ab,abb}. 

To  show  this  result,  we  need  the  following  definition  and  Lemma. 

Definition:  A  language  P  is  a  prefix  closed  language  if  for  any  s  that  belongs 
to  P  all  prefixes  of  s  also  belong  to  P.  Note  that  a  prefix  closed  language  must 
contain  (.  Languages  {(,a  ,aa  ,aaa and  {£,0,06}  are  prefix  closed.  Language 
{£,06}  is  not  prefix  closed  because  it  does  not  contain  the  string  a,  a  prefix  of 
ab. 

Lemma  3.1:  For  any  prefix  closed  language  P,  if  an  FLSTOCS  machine  S 
adepts  it  then  it  is  also  accepted  by  a  FLSTOCS  machine  S'  with  only  final 
places. 

Proof:  Construct  S'  by  deleting  all  non-final  places  in  S.  Clearly 
L(S')CL{S),  since  a  path  that  can  be  traced  by  tokens  in  S'  can  also  be 
traced  in  S. 

Also  L(S)CL(S').  This  is  because  any  path  that  is  traced  for  accepting  a 
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string  in  S  cannot  pass  through  a  configuration  in  which  a  token  is  in  a  non¬ 
final  place,  otherwise  the  set  will  not  be  prefix  closed.  Q.E.D. 

Theorem  3.1:  There  is  no  FLSTOCS  machine  accepting  the  language 

P={e,a  ,b,ab,abb}. 

Proof:  Assume,  if  possible,  there  exists  a  FLSTOCS  machine  S  that  accepts  P. 
Since  P  is  a  prefix-closed  language,  by  Lemma  3.1,  we  can  convert  it  to  a 
machine  which  does  not  have  any  non-final  places. 

Since  the  string  ba  does  not  belong  to  the  language,  after  a  b  has  occurred 
in  the  input  string,  at  least  one  arc  labeled  a  should  be  disabled.  The  only 
way  an  occurrence  of  6  can  disable  a  transition  labeled  a  is  by  removing  all 
tokens  in  the  source  place  of  an  arc  labeled  a.  For  this  to  happen  there  must 
be  an  arc  labeled  6  leaving  this  place.  This  means  that  after  the  first  6  appears 
in  the  input  string,  the  arc  labeled  6  will  also  be  disabled  since  there  will  be  no 
tokens  in  its  source  place.  Hence  S  will  reject  the  string  abb.  Q.E.D. 

From  the  above  discussion,  we  note  that  a  DSTOCS  machine  combines 
capabilities  for  checking  that  symbols  are  in  proper  sequence  by  means  of  reg¬ 
ular  sets,  and  for  checking  that  symbols  are  in  proper  count  by  means  of 
FLSTOCS  machine.  As  an  application  of  DSTOCS  machines  we  show  a 
DSTOCS  machine  in  Figure  3.7  which  accepts  all  valid  arithmetic  expressions. 
Unit  1  is  a  finite  stale  machine  which  checks  the  sequence  of  all  symbols 
without  counting  them.  Unit  2  uses  a  *-places  to  count  the  number  of 
parentheses.  • 
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Figure  3.7:  A  DSTOCS  machine  to  Parse  Arithmetic  Expressions 


6.  Semantics  of  the  STOCS  Model 

In  the  following  section,  we  provide  an  extensional  theory  of  STOCS 
machines.  Our  theory  of  concurrent  processes  is  built  on  following  assump¬ 
tions: 

(1)  Non-simultaneity  of  Events.  We  assume  that  two  events  cannot  be 
observed  simultaneously.  If  the  simultaneity  of  a  set  of  events  is  impor¬ 
tant  (e.g.  in  synchronization),  wc  represent  the  set  of  events  as  a  single 
event  occurrence.  If  the  simultaneity  is  not  important,  we  allow 
occurrences  of  events  to  be  recorded  in  any  order.  Milner,  who  uses  the 
same  assumption  in  his  proposal  of  CCS,  justifies  it  by  quantum  theory 
which  states  that  the  flow  of  information  is  bounded  by  the  speed  of  light 
and  therefore  if  two  events  happen  simultaneously,  they  will  be  recorded 
at  different  times  by  the  observer.  This  assumption  also  makes  the  entire 
theory  more  elegant  and  tractable. 


39 


(2)  Atomicity  of  an  Event;  Id  this  theory  we  will  ignore  detailed  tim¬ 
ing  consideration  of  events,  and  each  event  will  be  considered  atomic  in 
nature.  Thus,  no  analysis  can  make  an  assumption  about  the  time  dura¬ 
tion  of  events.  A  time-consuming  action  is  represented  by  a  pair  of  events, 
the  first  denoting  its  start  and  the  second  denoting  its  end.  The  interval 
between  these  events  represents  the  duration  of  the  event  and  it  may 
overlap  with  other  events. 

(3)  Non-probabilistic  Analysis;  We  will  not  make  any  distinction 
between  two  systems  that  show  the  same  possible  behavior  but  each 
behavior  with  different  probability.  For  example,  a  coin  which  on  a  toss 
shows  head  with  probability  0.6  is  considered  equivalent  to  a  coin  which 
shows  head  with  probability  0.5  but  different  from  coins  which  show  head 
with  probability  either  0  or  1. 

(4)  Non-randomness  in  Execution.  We  call  a  machine  non-random  if 
for  any  string,  the  machine  either  accepts  or  reject  the  string,  but  will 
always  return  the  same  answer.  Thus  the  .set  of  strings  that  are  rejected 
is  the  exact  complement  of  the  set  of  strings  that  are  accepted.  STOCS 
machines  that  can  return  different  answers  for  the  same  input  at  different 
times  are  called  Uncontrollable  STOCS  (USTOCS)  machines  and  are  the 
subject  of  Chapter  6. 

With  above  assumptions,  we  are  ready  to  define  equivalence  of  two 
STOCS  Machines.  We  call  two  concurrent  systems  equivalent  if  an  external 
observer  cannot  distinguish  between  the  two  systems  no  matter  how  different 
their  internal  structure.  The  observer  (or  environment)  is  allowed  to  give  an 
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input  string  to  the  machine  and  observe  whether  the  machine  accepts  or 
rejects  it.  Since  for  deterministic  processes,  a  string  is  always  either  accepted 
or  rejected,  all  strings  that  do  not  belong  to  the  acceptance  set  are  always 
rejected.  The  external  behavior  of  these  processes,  therefore,  can  be  character¬ 
ized  as  a  tuple  (L  ,  L)  where  E  represents  the  set  of  events  that  the  process 
engages  in  and  L  is  the  language  of  the  STOCS  machine.  Formally, 

Definition:  Two  STOCS  machine  A/j  and  A/2  are  equivalent  if  their  alphabet 
and  language  is  the  same. 

The  alphabet  of  a  machine  is  the  set  of  events  a  machine  can  possibly 
engage  in.  For  example,  the  machine  in  example  3.1  can  only  engage  in  {pre. 
req.  crit,  rcl,  post}  and  therefore  cannot  engage  in  event  put^item.  The  fol¬ 
lowing  STOCS  machines  are  considered  equivalent.  Both  of  them  consist  of  a 
single  unit  as  shown  in  the  Figure  3.8.  The  behavior  of  both  the  machines  can 
be  characterized  as  ((a ,6,c),(fl6,oc)).  On  the  other  hand,  the  machines  shown 
in  Figure  3.9  are  different  because  their  behaviors  are  ((0 ,6,c ),())and((o ,6).()) 
re.spectively. 

7.  Modeling  by  the  STOCS  Model 

In  tiiis  section,  we  provide  paradigms  for  modeling  by  the  STOCS  formal¬ 
ism. 

7.1.  Event  and  Conditions 

A  condition  is  modeled  using  place,  and  events  are  modeled  using 
handshakes.  An  event  that  depends  on  conditions  of  multiple  entities  is  shared 
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Figure  3.8;  Equivalent  STOCS  Machines 


^  =  {0.  b,  c) 


E  =  {a,  6} 


Figure  3.9;  Different  STOCS  Machines 

by  multiple  units.  For  example,  consider  the  problem  of  modeling  a  simple 
machine  shop,  ^'a^ious  conditions  and  events  for  the  system  are  as  follows. 
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condition: 

si;  order  arrived  and  waiting 
s2:  order  being  processed 
s3:  order  complete 
s5:  machine  shop  waiting 
s6;  machine  working  on  the  order 
events: 

el:  an  order  arrives 
e2:  processing  starts 
e3:  processing  completes 
e4;  order  delivered 


Orders  Machine 


Figure  3.10;  A  STOCS  machine  for  machine  shop  modeling 

Figure  3.10  shows  a  STOCS  machine  for  modeling  the  machine  shop.  Let 
us  consider  a  more  complex  situation  to  bring  out  the  advantages  of  modular¬ 
ity  in  the  STOCS  model.  The  machine  shop  may  have  three  machines  -  Ml, 
M2  and  M3.  It  may  have  two  operators  Fl  and  F2.  An  order  needs  two 
stages  of  machining.  First,  they  must  be  machined  by  Ml  and  then  by  either 
M2  or  M3.  Fl  can  operate  Ml  and  M2  while  F2  can  operate  Ml  and  M3.  Fig¬ 
ure  3.11  shows  the  modeling  by  a  Petri  net  and  Figure  3.12  shows  its  modeling 
by  a  STOCS  Machine.  In  the  STOCS  machine  the  communication  is  hidden, 
each  process  is  specified  independently.  This  means  that  it  is  easier  to  under¬ 
stand  and  write  specifications  in  the  STOCS  model.  It  is  also  easier  to  specify 
a  partially  developed  system. 
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Figure  3.11:  A  Petri  Net  for  Complex  Shop  modeling 
1 .2.  Concurrency  and  Choice 

The  concurrency  is  present  in  the  model  as  more  than  one  transition  can 
be  enabled  at  one  lime.  In  Figure  3.13,  a  and  6  model  concurrency  as  they 
can  be  fired  in  any  order.  The  choice  is  modeled  in  the  system  by  means  of 
multiple  arcs  emanating  from  a  single  node.  For  example,  in  Figure  3.13  either 
a  or  b  can  fire  but  not  both. 
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Orders 


Figure  3.12:  A  STOCS  Machine  for  Complex  Shop  modeling 
7.3.  Linear  Constraints  on  the  Language 

We  can  also  model  .systems  specified  by  constraints  posed  on  their  event 
sequences.  One  of  the  main  weaknesses  of  the  finite  state  model  was  its  inabil¬ 
ity  to  count  an  arbitrary  number  of  instances  of  an  event.  Thus  it  cannot 
accept  languages  L  =  {a". 6"  lfl,6€S,u>0}.  The  language  L  can  be  written 
as  the  conjunction  of  two  constraints: 

(1)  All  a’s  precede  all  6’s. 

(2)  the  number  of  a’s  =  the  number  of  6’s 

The  first  constraint  can  be  checked  by  a  finite  state  machine  corresponding  to 
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Choice  Concurrency 


Figure  3.13:  STOCS  Machine  representing  Choice  and  Concurrency 
the  regular  expression  a*b*,  but  the  second  constraint  can  not  be  checked  by  a 
finite  state  machine  due  to  the  pumping  lemma.  If  represents  the  number 
of  a's  in  the  string  and  A'j,  represents  the  number  of  b's  in  the  string,  the 
second  constraint  can  be  written  as  n^=nf^.  Figure  3.7  shows  a  STOCS 
machine  for  L  with  two  units,  one  for  each  constraint.  To  illustrate  the  model¬ 
ing  power  of  STOCS  machines,  we  also  show  the  modeling  of  following  con¬ 
straints  in  Figure  3.14. 

(1) 

(2)  v,=2nt, 

7.4.  Interaction  Between  Multiple  Systems 

It  is  easy  to  capture  the  interaction  between  multiple  systems  by  means  of 
shared  handshakes  and  the  definition  of  synchronous  execution.  Thus,  if  Mi 
and  A/2  are  two  STOCS  machines  consisting  of  {Ui,U2-X'm) 
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a 


Figure  3.14;  STOC'S  Machines  to  model  integral  linear  constraints 
(I  I'.f  o'.. then  the  STOCS  machine  resulting  from  their  interaction  is 
simply  The  interaction  between  these  STOCS  machines  fol¬ 

lows  from  the  definition  of  synchronous  execution.  A  synchronous  handshake 
requires  that  all  units  with  that  particular  handshake  in  their  handshake  set 
participate.  Therefore,  a  handshake  which  could  have  taken  place  before  com¬ 
position  with  another  STOCS  machine  may  have  to  wait  for  units  in  the  other 
STOCS  machine  to  synchronize. 

For  example,  consider  a  chocolate  vending  machine.  There  are  two  kinds 
of  events:  choc,  which  is  the  dispensing  of  a  chocolate,  and  coin,  which  is  the 
depositing  of  a  coin  by  the  customer.  The  machine  owner  specifies  that  the 
number  of  choc  events  should  be  less  than  or  equal  to  the  number  of  coin 
events  (Figure  3.15).  The  customer,  on  the  other  hand,  will  not  deposit  a  coin 
until  he  receives  the  chocolate  for  his  last  coin  (Figure  3.15).  Hence,  when 
these  two  machines  interact,  the  only  feasible  sequence  of  events  is  coin  choc 
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coin  choc  etc. 


Machine  Customer 

coin  coin 


choc  choc 


Figure  3.15;  A  STOCS  machine  for  a  Chocolate 
Vending  Machine  and  a  Customer 

8.  Conclusions 

In  this  chapter,  we  have  defined  a  transition  based  model  called  the  Syn¬ 
chronous  Token  based  Communicating  State  (STOCS)  model.  A  STOCS 
machine  consists  of  units,  each  of  which  models  a  set  of  non-interacting 
processes.  We  have  presented  many  examples  modeled  by  STOCS  machines. 
STOCS  machines  can  easily  model  concurrency  and  synchronization  making 
them  useful  for  specifying  concurrent  systems.  We  have  shown  how  STOCS 
machines  can  act  as  acceptors  of  strings.  We  have,  thus,  defined  the  language 
of  a  STOCS  machine.  Based  on  the  language  and  the  alphabet  of  a  STOCS 
machine,  we  have  defined  the  equivalence  between  two  STOCS  machines. 
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CHAPTER  4 


An  Algebraic  Characterization  of  STOCS 


1.  Introduction 

In  Chapter  3,  v,e  describe  a  transition  based  model  to  dehne  a  process.  An 
alternative  approach  to  specifying  a  concurrent  system  is  based  on  algebra.  In 
this  approach,  a  system  is  built  by  applying  algebraic  operators  on  sub-systems 
in  a  well  defined  manner.  An  equivalence  of  a  transition  based  model  and  an 
algebraic  model  provides  us  the  flexibility  of  specifying  a  system  in  an  alge¬ 
braic  model  and  analyzing  it  in  automaton  model  and  vice-versa.  For  example, 
finite  state  machines  and  their  equivalent  algebraic  expressions  (regular  expres¬ 
sions)  serve  as  an  excellent  vehicle  for  specification  of  sequential  systems.  A 
finite  state  machine  has  an  equivalent  regular  expression,  means  that  the 
language  characterized  by  them  is  identical.  Many  tools,  such  as  LEX,  take 
advantage  of  this  equivalence  to  convert  specifications  expressed  in  algebra 
based  models  to  transition  based  models  for  lexical  analysis  of  programming 
languages.  In  this  chapter,  we  define  concurrent  regular  expressions  and  show 
that  they  are  equivalent  to  General  STOCS.  Figure  4.1  summarizes  the  rela¬ 
tionships  between  various  transition  based  and  algebraic  models. 

We  shall  use  the  following  naming  conventions.  Words  in  lower  case 
denote  distinct  events,  e.g.  get,  put,  a,  b.  The  letters  A,B,C  stand  for  either 
the  concurrent  regular  expressions  or  the  language  of  a  process  characterized 
by  them. 
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This  chapter  is  organized  as  follows.  Section  2  de6nes  concurrent  regular 
expressions.  Section  3  shows  examples  of  concurrent  systems  modeled  by  con¬ 
current  regular  expressions.  Section  4  establishes  their  equivalence  with 
STOCS  machines.  Section  o  describes  the  languages  characterized  by  con¬ 
current  regular  expressions. 

finite  state  machines  units  ^  STOCS  Machines 

I  I  I 

regular  expressions  ^  unit  expressions  Concurrent  regular  expressions 

Figure  4.1;  Relationship  between  t’^arious  Automata  and  Algebraic  Expressions 

2.  Concurrent  Regular  Expressions 

To  motivate  the  definition  of  concurrent  regular  expressions,  we  note  that 
regular  expressions  specify  the  computation  of  essentially  a  sequential  finite 
state  machine,  and  are  unsuitable  for  expressing  the  languages  of  the  con¬ 
current  machines.  To  specify  the  trace  of  a  concurrent  system,  we  have  pro¬ 
posed  an  extension  of  regular  expressions  (r.e.)  called  concurrent  regular 
expressions  (c.r.e.).  Recall  that  an  r.e.  over  an  alphabet  E  is  defined  as  follows: 

1)  Any  a  that  belongs  to  E  is  an  r.e.  defined  over  {a}. 

2)  If  A  and  B  arc  r.e.’s  defined  over  E^  and  E^,  then  A.B  (concatenation)  and 
A-l-B  (or)  are  r.e.’s  defined  over  E^U^b,  and  A*  (Kleene  closure)  is  an  r.e. 
defined  over  E. 

For  example,  if  E  =  {o,6}  then  a*b-\-b*a ,abb,ab+ba  are  some  examples 
of  regular  expressions  defined  over  E.  To  define  concurrent  regular  expressions 
we  add  the  following  operations:  ||  ,  q,  [].  With  these  additional  operators  we 
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define  a  concurrent  regular  expressions  (c.r.e.)  over  an  alphabet  E.  A  c.r.e.  A 
is  characterized  by  two  sets  -  its  alphabet  set  (E^),  and  its  language  (L^). 
Even  though  a  concurrent  regular  expression  is  defined  over  E,  we  will  not 
explicitly  use  E  in  defining  concurrent  regular  expressions.  Any  binary  opera¬ 
tor  over  two  different  alphabet  set  results  in  a  concurrent  regular  expression 
defined  over  the  union  of  two  alphabet  sets.  Thus  the  expression  A  op  B  is 
always  defined  over  E^U^e  As  a  result,  we  will  also  treat  in  this  chapter  a 
c.r.e  A  synonymous  to  its  language 

2.1.  Definition 

(1)  Any  a  that  belongs  to  E  is  a  regular  expression  (r.e.)  defined  over  {a}.  A 
special  symbol  called  c  is  also  a  regular  expression  defined  over  {}.  If  A 
and  B  are  r.e.’s,  then  so  are  A.B  (concatenation),  A-l-B  (or).  A*  (Kleene 
closure). 

(2)  A  regular  expression  is  also  a  vnit  expression.  If  A  and  B  are  unit  expres¬ 
sions  then  so  are  .4®,  B®,  and  A|1B. 

(3)  Any  unit  expression  is  also  a  concvrrenf  regular  expression.  If  A  and  B 
are  concurrent  regular  expressions  then  so  is  A[]B, 

Examples  of  some  valid  concurrent  regular  expressions  are 
(a  *6)“||6*c[](a6)®  and  (a6)®j|(6a )“.  Some  invalid  concurrent  regular  expressions 
are  (a6)“(6c)®  and  ((a6)'^[j(ac)*)®.  These  expressions  are  not  valid  because 
they  use  the  q  operator  in  a  manner  not  permitted  by  the  syntax.  Table  4.1 
summarizes  semantics  of  all  the  operators  described  by  an  example. 
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Operator 

Name 

Result 

Choice 

{a6,6a } 

A.B 

Concatenation 

{fl66a } 

A* 

Kleene  Closure 

{e,a6,a6a6,..} 

AllB 

Interleaving 

{a66a  ^abab ,baab  ,baha  } 

A^  . 

Alpha  Closure 

{t,ab,abab,aabb,..) 

A[1B 

Composition 

{} 

Table  4.1:  Example  for  A  =  {06}  and  B  =  {ba} 
2.2.  Choice,  Concatenation  and  Kleene  Closure 

These  are  the  usual  regular  expression  operators. 

Choice  between  two  set  of  strings  is  defined  as  follows. 

A-\-B=A\jB 

For  e  g.  if  A  =  {ab,bo}  and  B  =  {a,c}  then  A+B  =  {ab,bc,a,c}. 
Concatenation  of  two  sets  of  strings  is  defined  as  follows. 

A.B  =  {u'/u'~s.t  where  seA  A  teB}. 

Kleene  closure  of  a  set  A  is  defined  as 
.4  =  U  A> 

t=0.1,.. 


Properties  of  these  operators  are  as  follows; 


1 1  A+A  =  A 

2)  A+B  =  B+A 

3)  A+(B+C)  =  {A+B)+C 

4)  A+d  =  A 

5)  A.(B.C)  =  (A.B).C 

6)  A.{f}  =  A 

7)  A.(B+C)  =  A.B  +  A  C 

8) (AT  =  A* 

For  details  of  these  operators  the  reader  is  referred  to  (Hopcroft  79) 
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2.3.  Interleaving 


To  define  concurrent  operations,  it  is  especially  useful  to  be  able  to 
specify  the  interleaving  of  two  sequences.  Consider  for  example  the  behavior  of 
two  independent  vending  machines  V^ll  and  V^12.  The  behavior  of  may 
be  defined  as  (coin. choc)*  and  the  behavior  of  \^f2  as  (coin. coffee)*.  Then  the 
behavior  of  the  entire  system  would  be  interleaving  of  \'M1  and  \^12.  With 
this  motivation,  we  define  an  operator  called  interleaving,  denoted  by  ||.  Inter¬ 
leaving  is  formally  defined  as  follows: 

a||£=£||a=a  V/aeH 

a.s||6./  =  a.(s||fc.O  U  6  (a.s||0  \/a,beT,,  s,te^* 

Thus,  ab\\ac  =  {abac,aabc,aacb,acab}.  This  definition  can  be  extended  to 
interleaving  between  two  sets  in  a  natural  way,  i.e. 

A  II  B  =  {u73s€.4  a  t€J9,U'6s||/} 

For  example,  consider  two  sets  A  and  B  as  follows:  A  =  {o6,c}  and  B  =  {ba } 
then  A  II  B  =  {abba  ,abab ,baab , baba  ,cba  ,bca  ,bac} . 

Note  that  similar  to  A  ||  B,  we  also  get  a  set  A  ||  A  =  {oa66,o6a6}.  We 
denote  A  ||  A  by  We  use  parentheses  in  the  exponent  to  distinguish  it 
from  the  traditional  use  of  the  exponent  i.e.  A^=A.A. 

Properties  of  || 

(1)  Interleaving  is  commutative,  i.e., 

A||B  =  B||A 

(2)  Interleaving  is  associative,  i.e.. 
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A  II  (B  II  C)  =  (A  II  B)  II  C 

(3)  Epsilon  is  the  identity  of  interleaving,  i.e. 

A||{f}=A 

(4)  The  null  set  is  the  zero  of  interleaving,  i.e. 

A\\d  =  <f> 

(5)  Interleaving  distributes  over  choice,  i.e. 

(A+BI II  C  =  (A  II  C|+(B  II  C) 

Due  to  the  fifth  proposition,  we  will  use  A+B  ||  C  to  mean  A+(B  ||  C)  rather 
than  (A+B)  ||  C.  We  also  give  higher  precedence  to  ||  than  Therefore  A.B 
(I  C  would  mean  A.(B  ||  C)  rather  than  (A.B)  ||  C.  It  is  easy  to  see  that  the  . 
does  not  distribute  over  ||  and  vice-versa.  The  use  of  the  ||  operator  generally 
results  in  a  set  which  is  exponentially  bigger  than  its  arguments.  In  terms  of 
cardinality  we  note  that 

(1)  lA+BI  <  lAI  +  IBl  (where  +  is  the  arithmetic  sum) 

(2)  lA.Bl  <  I A 1.  IBl  (where  .  is  the  arithmetic  product) 

(3)  I  A||B  I  <S  ^  ^  ^  ^  \lxeAAyeB.  This  operator,  however,  does 

I  T  M  I  y  1 ' 

not  increase  the  modeling  power  of  concurrent  regular  expressions  as  shown  by 
the  following  Lemma. 

Lemma  4.1:  Any  expression  that  uses  ||  can  be  reduced  to  a  regular  expres¬ 
sion  without  II  . 

Proof:  The  interleaving  of  two  regular  expressions  is  also  a  regular  expression 
[Hopcroft  79].  Q.E.D. 
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For  example  (a6||6c)  can  be  written  as  (abbc+abcb+babc-^-bcab)  and  a||6"^ 
can  be  written  as  b*ab*. 

2.4.  Alpha  Closure  -  a 

Consider  the  behavior  of  people  arriving  at  a  supermarket.  We  assume 
that  the  population  of  people  is  infinite.  If  each  person  Cl’ST  is  defined  as 
(enter. buy. leave),  then  the  behavior  of  the  entire  population  is  defined  as  inter¬ 
leaving  of  any  number  of  people.  With  this  motivation,  we  define  an  analogue 
of  a  Kleene-Closure  for  the  interleaving  operator,  alpha-closure  of  a  set  A, 
denoted  by  A®  as  follows: 

y 

‘■=0,1,.. 

In  the  above  example,  CUST  =  (enter. buy. leave)  CVST*  = 
{u'  I  u'e{en(er+buy+leai'e)*,i^enter>i^buy>^leave  for  any  prefix 
.^ent€r=:^buys—i^leave} 

We  use  #  a  to  mean  the  number  of  occurrences  of  symbol  a  in  any  string. 
Thus  if  a  string  =  {aabba}  then  #a  =  3  and  #b  =  2. 

Note  the  difference  between  Kleene  closure  and  alpha  closure.  The 
language  shown  above  cannot  be  accepted  by  a  finite  state  machine.  This  can 
be  shown  by  the  use  of  the  pumping  lemma  for  finite  state  machines  [Hoperoft 
79].  We  conclude  that  alpha  closure  can  not  be  expressed  using  ordinary  r.e. 
operators. 

Intuitively,  the  alpha  closure  lets  us  model  the  behavior  of  an  unbounded 
number  of  identical  independent  sequential  agents. 
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As  S*  forms  a  monoid  under  .  (concatenation),  E®  forms  a  commutative 
monoid  under  the  operation  ||.  This  is  because  it  is  closed  under  ||  ,  ||  is  com¬ 
mutative  and  associative,  and  {<}  is  left  and  right  identity.  As  Kleene  closure 
makes  a  set  closed  with  respect  to  concatenation,  alpha  closure  makes  a  set 
closed  under  interleaving.  We  will  use  this  intuition  to  provide  an  alternative 
definition  of  alpha  closure. 

Definition:  A  set  A  is  called  closed  under  interleaving,  or  simply  i-closed,  if 
for  any  two  strings  S|  and  S2  necessarily  distinct)  that  belong  to  A,  SjUso 
is  a  subset  of  A.  By  definition  <  must  also  belong  to  an  i-closed  set. 

E.vamples:  {c},  {(,a  are  example  of  i-closed  sets.  As 

Kleene  closure  of  a  set  A  is  the  smallest  set  containing  A  and  closed  under 
concatenation,  alpha  closure  of  a  set  A  is  the  smallest  set  containing  A  and 
closed  under  interleaving.  More  formally, 

Theorem  4.1:  Let  A  be  a  set  of  strings.  Let  B  be  the  smallest  i-closed  set  con¬ 
taining  A.  Then  B  =  A®. 

Proof;  A®  contains  A  and  is  also  i-closed.  Since  B  is  smallest  set  with  this 
property,  we  get  PC  A®. 

Since  B  is  i-closed  and  it  contains  A,  it  must  also  contain  A^*^  for  all  i. 
This  implies  that  B  contains  A®.  Combining  with  our  earlier  argument  we  get 
B  =  A®.  Q.E.D. 

The  above  theorem  tells  us  that  as  Kleene  closure  captures  the  notion  of  doing 
some  action  any  number  of  times  in  series,  alpha  closure  captures  the  notion  of 
doing  gome  action  any  number  of  limes  in  parallel.  Note  that  if  a  set  A  is  i- 
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closed,  it  is  also  concatenation  closed.  This  is  because  if  S|  and  S2  belong  to  A 
then  so  does  SiHso-  particular  61.62-  The  following  corollary  provides 

us  a  method  of  finding  A‘^  by  showing  that  the  set  is  i-closed. 

Corollary;  A  set  A  is  i-closed  if  and  only  if  A  =  A®. 

Proof;  If  A  is  i-closed.  it  is  also  the  smallest  set  containing  A  and  i-closed.  By 
Theorem  4.1,  it  follows  that  A  =  A®. 

Conversely,  A  =  A®  and  A®  is  i-closed  therefore  A  is  also  i-closed. 

Q.E.D. 

The  above  corollary  tells  us  that  if  a  set  is  i-closed,  then  its  alpha  closure  is 
the  same  as  itself.  As  an  application  of  this  corollary,  we  get  A®'*=A®. 

The  following  Theorem  tells  us  that  interleaving,  Kleene  closure  and 
alpha  closure  of  i-closed  sets  remain  i-closed.  Combining  Theorem  4.2  with  the 
previous  corollary,  we  can  find  alpha  closure  of  sets  that  are  built  of  some  i- 
closed  sets. 

Theorem  4.2;  If  A  and  B  are  i-closed  then  so  are  A  II  B,A*,A®. 

Proof: 

1)  A  II  B;  Let  «j  and  So  belong  to  A  j|  B.  We  will  show  that  SjUso  a  subset 
of  A  II  B. 

«iepi||?i  because  Sj  belongs  to  A  ||  B  ,  for  some  pjeA.gjeB. 

*2^/’2ll92  because  So  belongs  to  A  ||  B  ,  for  some  p2€A,7o6B. 

«ill«2^PilkjllP2lk2 

=  Pil|P2lkilk2  (II  associative  and  commutative) 

=  p\\q  where  p=p,||p2  and  q  =  j,||g2 
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C  A  II  B  (because  p  C  A  and  q  C  B  as  A  and  B  are  i-closed) 


2)  A*;  Let  Sj  and  ^2  belong  to  A*.  We  will  show  that  S]||s2  a  subset  of  A*. 
=  Pi  P2  P3  -  Pii  "here  each  p,  belong  to  A 

=  9i  92  93  - -^Jii  "here  each  9,  belong  to  A 
Then  s^\\so  =  Pi-.p„||9i..9„,Cpi||..p„l|..9j||..9^ 

CA  (A  is  i-closed) 

C  A* 

3)  A'^:  From  Theorem  4.1.  Q.E.D. 

Applying  Theorem  4.2.  we  can  easily  deduce  the  following  identities. 

1)  (.4|1B)®=A||B  if  A  and  B  are  i-closed 

2)  .4  **^=.4*  if  A  is  i-closed 

For  example,  let  Cl'STj^  and  CVST^  be  sets  of  strings  denoting  behavior  of 
customers  in  supermarket  A  and  B  respectively.  Both  CVST^  and  CVSTg  are 
i-closed  and  therefore,  by  Theorem  4.2  CL'5r4||C’(^57'^  is  also  i-closed. 

The  above  theorem  also  tells  us  that  the  set  of  all  i-closed  sets  forms  a  commu¬ 
tative  monoid  under  the  operation  j|.  This  is  because  they  are  closed  under  || 

,  II  is  commutative  and  associative,  and  {(}  is  left  and  right  identity  of  this 
set.  As  shown  below,  the  other  binary  operations  defined  so  far  do  not  retain 
this  property. 

Theorem  4.3:  If  A  and  B  are  i-closed  then  A-t-B  and  A.B  may  not  be  so. 
Proof: 

1)  A-l-B:  Consider  A  =  {<16}®,  B={6f}®.  Let  Sj=a6  and  «2=bc.  Both  s, 
and  ^2  members  of  A-f-B  but  s=a66cesi||s2  ^^ot  belong  to  A-l-B. 
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2)  A.B;  Consider  A  =  {a6}®,^={6c}“.  Let  Sj=a66c  and  s^—abbc  Both  Sj 
and  S2  sr®  member  of  A.B  but  «=fl66cfl66c6Si||5o  does  not  belong  to  A.B. 
Q.E.D. 

Properties  of  alpha 

1)  A““=A“  (idempotence) 

2)  (absorption  of  *) 

So  far,  we  have  five  operations  on  sets  of  sequences.  These  are  ||,  a. 

Table  4.2  lists  the  class  of  languages  generated  by  using  some  important  sub¬ 
sets  of  these  operators. 


Operators 

II 

finite  languages 

■f...*,  II 

regular  languages 

■f,..*,  II  ,  constrained  use  of  a 

unit  languages 

Table  4.2:  Operators  and  Languages 
2.5.  Synchronous  Composition 

To  provide  synchronization  between  multiple  systems,  we  define  a  compo¬ 
sition  operator  denoted  by  {].  Intuitively,  this  operator  ensures  that  all  events 
that  belong  to  two  sets  occur  simultaneously.  For  example  consider  a  vending 
machine  described  by  the  expression  {coin.choc)*.  If  a  customer  CUST 
wants  a  piece  of  chocolate  he  must  insert  a  coin.  Thus  the  event  coiti  is  shared 
between  and  CUST.  The  complete  system  is  represented  by  \^1[]CUST 
which  requires  that  any  shared  event  must  belong  to  both  \^1  and  CUST. 
Formally, 
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A(]B  ={u;  I  u’/I:^€A,u'/Eb€B} 


u'/S  denotes  the  restriction  of  the  string  w  to  the  symbols  in  S.  For  example, 
acab/{a,b}  =  aab  and  aco6/{6,c}  =  cb.  If  A  =  {ab}  and  B  =  {6a},  then 
A[]B  =  <t>  as  there  cannot  be  any  string  that  satisfies  ordering  imposed  by  both 
A  and  B.  Consider  another  set  C  =  (ac }.  Then  A[]C  =  {a6c,af6}. 

Properties  of  [] 

Many  properties  of  (]  are  the  same  as  those  of  the  intersection  of  two  sets. 
Indeed,  if  both  operands  have  the  same  alphabet  then  [|  is  identical  to  intersec¬ 
tion. 

(1) A[]A  =  A  (Idetnpotence) 

(2)  A[]B  =  B[jA  (Commutativiiy) 

(3)  A[](B|]C)  =  (A[]B)[]C'  (Associativity) 

(4)  A1]NULL'=  NULL,  NULL  =  (zero  of  (]) 

(o)  A[jM\X  =  A.  ^L•VX  =  (E4,E_4*)  (identity  of  []) 

(0)  A[|(B-t-C)  =  (A[]B)-f-(.-\[]C)  (Distributivity  over  -h) 

We  next  sliow  that  []  is  a  well  behaved  operator  in  the  sense  that  on  com¬ 
bining  two  i-closed  sets  with  {],  the  re.sulting  set  is  also  i-closed. 

Theorem  4.4:  If  A  and  B  are  i-closed  then  so  is  A[]B. 

Proof:  Let  Si  and  So  belong  to  A[)B.  Then 
«i/E^€.4  and 

Similarly,  SofZ^eA  and  So/^b^^- 
We  will  show  that  SiHso/E^CA  and 

«i||«o/Ey^ 
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=Si/E^||s2/^x  (Restriction  distributes  over  ||  ) 

CA  (A  is  i-closed) 

and  similarly,  fii||s2/DB=Sj/Il5l|s2/^i?^^ 

Therefore,  Sj1|s2CA[]B.  Q.E.D. 

Consider,  for  example,  the  set  of  strings  denoting  the  behavior  of  custo¬ 
mers  at  a  supermarket.  That  is,  POP  =  {enter. bvy.leave)^*.  Now  assume  that 
for  buying  an  item  a  customer  has  to  interact  with  the  sales  clerk  whose 
behavior  can  be  written  as  CLERK  —  {buy}*.  Form  Theorem  4.4  we  con¬ 
clude  that  POP  []  CLERK  is  an  i-closed  set. 

3.  Modeling  of  Concurrent  Systems 

In  this  section,  wc  give  some  examples  of  use  of  concurrent  regular  exam¬ 
ples  in  modeling  concurrent  systems. 

Example:  (otc)“  [J  a*b*c*  accepts  the  language  {o”fc"c''  |n>0}.  Note  how 
the  use  of  a  operator  let  us  keep  track  of  the  number  of  different  symbols  that 
have  been  seen  in  the  string.  This  example  shows  that  the  strings  that  can  not 
be  recognized  even  by  pu^h  down  automata  can  be  represented  by  c.r.e’s. 

Example;  Consider  a  ball  room  where  both  men  and  women  enter,  dance  and 
exit.  Their  entry  and  exit  need  not  be  synchronized  but  it  takes  a  pair  to 
dance.  W’e  would  also  like  to  ensure  that  the  number  of  women  in  the  room  is 
always  greater  than  or  equal  to  the  number  of  men,  since  idle  men  can  be 
dangerous!  This  system  can  be  easily  represented  using  a  concurrent  regular 


expression: 


A  man’s  actions  can  be  represented  by  the  following  sequence: 
man  ::  menier  dance  mexit 
A  woman’s  actions  as  follows: 
woman  ::  wenter  dance  wexii 

The  constraint  that  the  number  of  women  always  be  greater  can  be 
expressed  as: 

constraint  ::  {u’enter  (menter  mexit}*  wexit)^^ 

Since  any  number  of  men  and  women  can  enter  and  exit  independently 
(except  for  the  constraint)  the  entire  system  is  modeled  as  follows: 

man^  []  woman^  []  constraint 

Example:  Consider  the  office  of  the  Department  of  Motor  Vehicles.  Two 
types  of  clients  need  service,  those  who  need  to  get  their  picture  ID  taken  and 
those  who  need  to  take  a  test.  Clients  who  need  their  picture  taken  first  pay 
the  fee  and  then  get  their  picture  taken.  Those  taking  the  test,  first  pay  the 
fee,  then  take  the  lest  and  then  receive  the  results  of  the  test.  Let  us  say  that 
there  are  two  clerks  -  John  and  Mary  -  who  serve  the  clients.  John  receives 
tlie  fee  and  Mary  hands  out  results.  However  the  camera  is  so  complicated 
that  it  requires  both  John  and  Mary  to  operate  it. 

The  relevant  CRE’s  are  : 

client  1  ;:  fee  picture 
client2  ::  fee  test  result 
John  ::  {fee  +  picture)* 

Mary  ::  {result  +  picture)* 
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Di\r\’  ::  {{clientl)°  ||  (c/icn/2)“)  []  (John)  []  (Mary) 

4.  Relationship  between  Concurrent  Regular  Expressions  and 
STOCS 

In  this  section,  we  show  that  any  STOCS  machine  can  be  converted  to  its 
equivalent  concurrent  regular  expression  and  viceversa.  We  need  to  show  the 
following  Lemmas  to  prove  the  result  establishing  the  equivalence  of  STOCS 
and  concurrent  regular  expressions. 

Lemma  4.2:  Any  unit  with  multiple  ^-places  can  be  converted  to  an 
equivalent  unit  with  a  single  ‘-place  (see  Figures  4.2(a)  and  4.2(b)). 

Proof:  Let  U  be  a  unit  with  multiple  ‘-places.  We  construct  U’,  a  unit  with  a 
single  ‘-place  by  merging  all  ‘-places  into  a  single  ‘-place.  All  input  arcs  and 
output  arcs  in  the  previous  units  are  combined.  If,  in  the  resulting  unit,  there 
is  more  than  one  arc  with  the  same  label  between  two  places  then  only  one  of 
them  is  retained.  Since  the  tokens  in  ‘-places  do  not  change  and  the  bag  of 
transitions  enabled  for  any  configuration  is  identical  for  U  and  U’,  we  conclude 
that  the  language  accepted  by  U  is  the  same  as  the  language  accepted  by  U’. 
Q.E.D. 

Lemma  4.3:  Any  unit  U  is  equivalent  to  another  unit  U’  which  has  at  most 
two  connected  components  -  one  with  ‘-place  and  the  other  with  a  single 
token  (see  Figures  4.2(b)  and  4.2(c)). 

Proof:  From  Lemma  4,2,  we  can  assume,  without  loss  of  generality,  that  there 
is  at  most  one  ‘-place  in  U.  U  may  have  one  or  more  connected  components. 
Let  the  connected  component  C  have  the  ‘-place.  C  may  have  tokens  at  some 
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simple  places  too.  As  tokens  move  independently  of  each  other  within  a  unit, 
C  can  be  written  as  two  components-  one  with  tokens  only  in  the  simple  place 
and  the  other  with  the  “-place  but  no  tokens  in  the  simple  place.  We  claim 
that  all  the  connected  components  with  no  “-places  can  be  combined  into  a 
single  connected  component  -  a  finite  state  machine.  This  is  because  there  is  a 
finite  number  of  tokens  residing  in  finite  places,  resulting  in  only  a  finite 
number  of  possible  configurations.  There  is  an  edge  labeled  a  from 
configuration  Cj  to  Co  if  and  only  if  configuration  Cj  can  result  in  C2  after 
making  a  transition  a.  A  finite  state  machine  can  be  simulated  by  a  connected 
component  with  a  single  token  in  its  initial  state.  Q.E.D. 


Figure  4.2  :  Lemma  4.2  and  4.3 

Lemma  4.4;  Let  U  be  a  unit  with  a  single  “-place  having  no  tokens  in  its  sim¬ 
ple  places.  Then  its  language  can  be  written  as  a  {regular  expression)^. 

Proof:  Let  C=(P,C,I!,6,F)  with  C(p,)  =  *.  We  construct  the  finite  state 
machine  A={P,p^,'£,S,F).  Let  L(X)  represent  the  language  accepted  by  auto¬ 
mata  X.  We  will  show  that  L{U)=L{A)**. 

Case  J:  L{U)CL{A)‘‘ 
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Let  a  string  s  belong  to  the  language  of  the  unit  U.  In  accepting  s,  a  finite 
number  of  tokens,  say  n,  must  have  moved  from  the  *-place  to  some  final 
place.  Let  SpSo-  ®.!  strings  that  are  traced  by  tokens  l..n,  respectively, 

such  that  one  of  their  interleaving  is  s.  Each  of  the  strings  also  belongs 

to  the  regular  set.  Therefore,  their  interleaving  belongs  to  alpha-closure  of  the 
regular  set. 

Case  2:  L(.4)“CL(L') 

Consider  any  string  s  in  LiA)^.  This  string  s  can  be  written  as  ail|s2ll-  ll^ri 
where  each  s,  belong  to  A.  As  s-  belong  to  A,  it  also  represents  a  path  from 
the  initial  place  to  a  final  place  in  U.  Hence  s  can  be  simulated  by  n  tokens 
which  simulate  Si,..Sn  respectively.  Q.E.D. 

Theorem  4.5:  There  exists  an  algorithm  to  derive  a  concurrent  regular 
expression  that  describes  the  set  of  strings  accepted  by  a  STOCS  machine. 

Proof ; 

Clearly  it  is  sufficient  for  us  to  derive  a  concurrent  expression  for  each  unit,  as 
the  concurrent  expression  equivalent  to  the  STOCS  will  be  the  concurrent  reg¬ 
ular  expressions  for  units  composed  by  the  []  operator. 

To  derive  the  expression  for  a  unit,  we  use  Lemma  4.3  to  convert  it  into  a 
unit  with  at  most  two  components,  one  with  *-place  and  one  with  a  single 
token.  From  Lemma  4.4,  the  language  of  any  such  unit  can  be  written  as 
interleaving  of  a  regular  expression  and  at  most  one  {regular  expression)^. 

For  example,  to  describe  the  language  of  the  unit  shown  in  Figure  4.2(a),  we 
first  convert  it  to  4.2(b)  by  Lemma  4.2.  We  convert  the  unit  in  4.2(b)  to  4.2(c) 
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by  Lemma  4.3.  There  are  two  connected  components  in  the  unit  of  Figure 
4.2(f').  The  regular  expression  for  the  first  component  W'ith  *  replaced  by  a 
single  token  is  (a.(b+c))*.  The  regular  expression  for  the  second  component  is 
(((6a'l-ro )*.a )*.((6a+ca )*.(6+c)).  Thus,  the  expression  for  the  entire  unit  can 
be  written  as  (a.(6+f )“||(((6a+cfl)*.a)*.((6o+co)*.(fc+f ))  Before  we  prove  the 
converse  of  the  above  Theorem,  we  need  the  following  Lemmas. 

Lemma  4.6;  (>tl|B)°  = 

(.4||B)  if  both  A  and  B  are  i*closed 
(A||B")  if  A  is  i-closed 
(.4‘^||£?)  if  B  is  i-closed 

C°  where  C  is  a  regular  set  if  both  A  and  B  are  regular  sets 

Proof: 

(1)  Both  A  and  B  are  i-closed. 

By  Theorem  4.2,  A  ||  B  is  i-closed. 

=  >  (.4l|B)"  =  A  II  B  by  Theorem  4.1. 

(2)  Only  A  is  i-closed. 

(.4||Br=(A''llBr  (because  A^=A) 

We  will  show  that  (A‘*||B)'*=A|1B“ 

We  first  show  that  aelA^jlB)®  *^«eA||B“ 
let  se(A“llB)“ 

■=>  6es,|(s2||s3..«^  where  m  >0. 

Q  (anll«l2  l|fllnJIMII(a2ll|a22ll  •a2njl<»2)  •ll••(fl,nll|am2ll  amr,JI<>m) 
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A,  B  i 'dosed 


Q 

A  regular,  B  regular 

(C  =  Al  IB) 

Figure  4.3:  Lemma  4.5 
where  a-j^A  for  »  =  and  ;=l..rj, 

On  rearranging  terms,  s  also  belongs  to  A\\B^ 

We  now  show  that  fi€.4||B*  ^s€(.4“||B)“ 

Let 

=  >  ll^illfcoim  ll^ni  ti'herew>0 
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c  Miiz^r 

(3)  Only  B  is  i-closed 
Similar  to  (2) 

(4)  Both  A  and  B  are  regular  =>  A  jj  B  =  C  as  interleaving  of  two  regular 
sets  is  also  a  regular  set.  =>  {A\\B)^=C° 

Lemma  4.8:  Let  A  and  B  be  Uvo  regular  expressions,  then 
Proof:  Let  string 

=#>seflil|02ll-  llanll^'ill^sll  -ll^m  for  a-eA,t‘=l..n, 

bj^B,j=\..m  n,m>0 

C(.4+B)“  (because  each  string  belong  to  A+B) 

Let  string  se(A+Bf. 
s€Cillcol|..|lf„,  where  r,€A+J5 
If  c,e.4  we  call  it  a,,  otherwise  we  call  it  6, 

on  rearranging  terms  so  that  all  strings  that  belong  to  A  come  before  strings 
that  do  not  belong  to  A  (and  therefore  must  belong  to  B),  we  get 
seA^WB^Q.E.D.. 

Lemma  4.7;  Any  unit  expression  I’  is  equivalent  to  another  unit  expression 
which  is  the  interleaving  of  regular  expressions  and  (regular  expression  Y‘. 
Expressions  in  these  forms  are  called  normalized  unit  expressions. 

Proof;  To  show  this  Lemma,  we  will  use  induction  on  the  number  of  times  (| 
or  a  occurs  in  a  unit  expression.  The  Lemma  is  clearly  true  when  the  expres¬ 
sion  does  not  have  any  occurence  of  ||  or  o  as  a  regular  expression  is  always 
normalized.  Let  1/  be  a  expression  with  at  most  k  occurrences  of  II  or  o. 
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Then  V  can  be  "written  as  Ui\\U2  or  Uf  where  (/j  and  U2  can  be  normalized 
by  the  induction  hypothesis.  We  will  show  that  U  can  also  be  normalized. 

\\U2 

V^=Ai\\Di°  where  A  and  B  are  some  regular  expressions 
Vn=A2\\B2^  where  A  and  B  are  some  regular  expressions 
Therefore,  r,|K '2=(-4,||Bi“)||(A2l|B2“) 

=  (Aill-lolIK^i^ll^s^)  (II  is  associative  and  commutative) 

=  (.4,11.40)11(55+52)^*  (l>y  Lemma  4.6) 

V  can  be  normalized. 

(2)  r=i7 

r=tT=(.4||5“)‘‘ 

where  A  and'B  are  some  regular  expressions. 

Since  is  i-closed  and  A  is  a  regular  set  from  Lemma  4.5,  we  obtain, 

r=.4i|5‘‘ 

=(.4+5)*^  (from  Lemma  4.6) 

=C^  for  some  regular  expression  C. 

. .  V  can  be  normalized.  Q.E.D. 

Theorem  4.6:  There  exists  an  algorithm  to  derive  a  STOCS  machine  that 
describes  the  set  of  strings  described  by  a  concurrent  regular  expression. 

Proof:  Any  regular  expression  can  be  converted  to  a  finite  state  machine  by 
standard  techniques  as  described  in  (Hopcroft  79). 

Using  Lemma  4.7  we  can  convert  any  unit  expression  into  the  normalized 
form.  To  convert  a  normalized  unit  expression  into  a  unit  we  simply  use  a 
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finite  state  machine  for  each  regular  expression  and  use  Lemma  4.5  to  con¬ 
struct  a  connected  component  with  a  *-place  for  {regular  expression )“. 
STOCS  is  just  the  union  of  all  units  constructed  by  the  above  procedure. 
Clearly,  the  STOCS  so  constructed  accepts  the  same  language  as  characterized 
by  the  given  concurrent  regular  expression.  Q.E.D. 

Thus,  the  class  of  languages  accepted  by  STOCS  and  concurrent  regular 
expressions  is  identical. 

Theorem  4.6  provides  us  the  flexibility  of  specifying  a  system  in  terms  of 
concurrent  regular  expressions  and  then  converting  it  to  a  Petri  Net  which  can 
be  analyzed  for  function  correctness  using  the  coverability  treejKarp  68], 
reachability  algorithm[Mayr  86]  and  matrix  eouations[Murata  84).  Figure 
4.4(a)  shows  an  example  of  a  Petri  net  which  is  converted  to  a  STOCS 
machine  shown  in  Figure  4.4(b).  The  concurrent  regular  expression  equivalent 
to  the  Petri  net  is  obtained  using  the  STOCS  machine  and  is  shown  in  Figure 
4.4(c). 


(c)  (a+6cV)  []  (ab*c)^ 

Figure  4  4  :  FLOPN  =>  STOCS  =>  CRE 
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6.  Concurrent  Regular  Languages 

From  our  earlier  results  we  know  that  the  class  of  language  accepted  by 
STOCS  is  identical  to  that  characterized  by  concurrent  regular  expressions. 
The  definition  of  concurrent  regular  expression  b  hierarchical  as  a  concurrent 
regular  expression  is  defined  using  unit  expressions  which  are  defined  using 
regular  expressions.  Regular  languages  are  those  set  of  strings  that  can  be 
accepted  by  a  regular  expression.  Unit  languages  are  those  set  of  strings  that 
can  be  accepted  by  a  single  unit  expression.  In  this  section,  we  show  that  the 
regular  languages  are  properly  contained  in  the  unit  languages  which  are  prop¬ 
erly  contained  in  the  concurrent  regular  languages. 

5.1.  Regular  Languages 

Theorem  4.7:  The  unit  languages  properly  contains  the  regular  languages. 

Proof;  As  a  finite  state  machine  is  also  a  unit  with  a  single  token,  unit 
languages  contain  regular  languages.  To  see  that  the  inclusion  is  proper,  con¬ 
sider  the  language  {(a. 6)®}.  which  is  accpeted  by  a  unit  in  Figure  4.5,  but  is 
not  accepted  by  a  finite  slate  machine. 

a 

unit  1 

b 

Figure  4.5:  A  unit  machine  for  (a6)“ 
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5.2.  Unit  Languages 


All  unit  languages  are  also  concurrent  regular  languages.  We  next  show 
that  this  containment  is  also  proper. 

Definition:  A  language  is  called  i—open  if  there  does  not  exist  any  non-null 
string  a  such  that  if  t  belongs  to  a  language  then  so  does  s\\t. 

Example;  All  finite  languages  are  i-open.  a*,(a-l-6)^,(a6)“  are  not  i-open 
because  a  ,aba  ,anda6  are  strings  respectively  such  that  their  interleaving  with 
any  string  in  the  languge  keeps  it  in  the  languge.  Recall  that  i-closed 
languages  are  set  of  strings  that  are  closed  under  interleaving.  All  i-closed 
languages  are  not  i-open  and  all  i-open  languages  are  not  i-closed.  However, 
there  are  languages  that  are  neither  i-open  nor  i-closed.  An  example  is 
a*6*j|c^  which  is  not  i-open  as  any  interleaving  with  c  keeps  a  string  in  the 
language.  It  is  not  i-closed  because  a6c||a6c  does  not  belong  to  the  language. 

Theorem  4.8;  A  unit  cannot  accept  a  non-regular  i-open  language. 

Proof:  Let  L  be  a  non-regular  i-open  language.  Since  this  language  is  not 
accepted  by  a  finite  state  machine,  the  unit  should  have  a  *-state.  For  the 
similar  reason  tokens,  must  move  out  of  the  *-state  and  must  eventually  reach 
a  final  state.  This  implies  that  there  exists  a  non-null  path  p  from  the  *-slate 
to  a  final  state.  This  implies  that  for  any  string  t  that  belongs  to  L,  /||p  will 
also  belong  to  L,  a  contradiction  because  L  is  an  i-open  language.  Q.E.D. 

For  example,  consider  the  language  A  2-stocs  for  this  language  is 

shown  in  Figure  4.6.  The  language  is  i-open  because  there  is  no  non-null 
string,  such  that  its  indefinite  interleaving  exists  in  the  language.  By  Theorem 
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4.8,  >ve  cannot  construct  a  single  unit  to  accept  this  language. 

Theorem  4.8  tells  us  that  unit  languages  are  properly  contained  in 
STOCS  languages.  Our  example  shows  that  there  exists  a  STOCS  machine 
with  two  units  -  one  with  a  *-stale  and  the  other  without  -  which  can  not  be 
accepted  by  a  single  unit.  Now  we  show  that  there  exists  two  units  both  with 
*-state  which  cannot  be  recognized  by  a  single  unit. 


b 


Figure  4.0:  A  STOCS  machine  for  (o i6])“[)(a2^i  *^2)^ 

Theorem  4.0:  There  are  i-closed  concurrent  regular  languages  that  cannot  be 
accepted  by  a  unit. 

Proof:  Consider  the  language  L  =  (oi6i)“'0(®2^j *^2)°  "’hich  can  obviously  be 
recognized  by  2-STOCS.  Assume  if  possible  that  it  can  be  recognized  by  a  sin¬ 
gle  unit.  Since  i^L,  there  are  no  tokens  in  the  non-final  places.  Therefore  any 
string  that  traces  a  path  from  a  *-place  to  a  final  place  is  also  a  member  of  L. 
We  show  that  there  exists  a  string  which  is  not  a  member  of  L  and  which 
traces  a  path  from  a  *-place  to  a  final  place. 

but  a2®i”^*^i"^2  not  belong  to  L  for  any  k >0.  This 
implies  that  while  making  transitions  on  Oj  the  symbols  must  move  out  of  *- 
place.  This  implies  that  there  is  a  path  from  the  *-place  to  the  final  place 
which  starts  with  a,.  Therefore,  the  machine  also  accepts  a  string  starting 
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with  the  symbol  Oj.  No  such  string  belongs  to  the  language.  Q.E.D. 

From  above  discussion,  we  note  that 
regular  C  unit  C  STOCS 

6.  Conclusions 

In  this  chapter,  we  have  defined  an  extension  of  regular  expressions  called 
concurrent  regular  expressions  and  have  shown  that  they  can  be  transformed 
to  STOCS  machines.  The  equivalence  of  STOCS  machines  and  CRE  formal¬ 
ism  is  comforting  as  we  can  specify  in  one  formalism  and  analyze  in  the  other. 
The  concurrent  regular  expression  is  built  of  regular  expressions  and  operators 
-  interleaving,  alpha  closure  and  synchronous  composition.  These  operators 
concisely  capture  two  notions  of  distributed  systems:  concurrency  and  syn¬ 
chronization. 
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CHAPTER  5 


Comparison  With  Petri  Nets 

1.  Introduction 

In  th  is  chapter,  we  do  a  detailed  comparison  of  STOCS  machines  with 
Petri  nets.  There  are  two  reasons  for  choosing  Petri  nets  for  comparison. 
First.  Petri  nets  have  been  used  extensively  in  the  design  and  analysis  of  con¬ 
current  programs  and  are  considerably  more  popular  than,  say,  UCLA  graphs 
or  computation  graphs.  Second,  we  have  shown  in  this  chapter  that,  loosely 
speaking,  the  power  of  the  STOCS  model  is  the  same  as  that  of  Petri  nets. 
Thus,  it  would  be  unfair  to  compare  the  STOCS  model  with,  say,  the  Finite 
State  Machine  Model,  which  is  less  powerful,  or  PRAM,  which  is  more  power¬ 
ful  than  the  STOCS  model. 

This  chapter  is  organized  as  follows.  Section  2  compares  the  complexity  of 
reachability  in  the  Petri  net  and  the  STOCS  model.  Section  3  compares  them 
for  ease  in  modeling  of  concurrent  systems.  Section  4  compares  their 
languages. 

2.  Comparison  of  Reachability 

In  this  section,  we  show  that  the  reachability  problem  is  equivalent  for 
Petri  nets  and  STOCS  machines.  This  gives  us  confidence  that  systems  that 
are  modeled  as  configurations  of  a  Petri  net  can  equivalently  be  modeled  as 
configurations  of  STOCS  machines.  Instead  of  showing  the  equivalence  of 
STOCS  machines  with  general  Petri  nets,  we  show  their  equivalence  with  ordi- 


nary  Petri  nets.  An  ordinary  Petri  net  is  a  special  case  of  a  general  Petri  net 
with  the  restriction  that  no  place  has  multiple  input  (or  output)  arcs  to  the 
same  transition.  We  can  restrict  our  focus  to  ordinary  Petri  nets  because  of 
the  follo\\ing  Lemma  due  to  Hack. 

Lemma  6.1  [Hack  76):  The  reachability  problem  is  equivalent  for  general 
Petri  nets  and  ordinary  Petri  nets. 

Proof;  Hack  provides  a  construction  to  convert  a  general  Petri  net  to  an  ordi¬ 
nary  Petri  net  such  that  the  reachability  problem  is  equivalent.  This  construc¬ 
tion  replaces  a  place  with  maximum  multiplicity  of  by  a  ring  of  k  places 
each  having  multiplicity  of  1  (see  Figure  5.1).  Q.E.D. 


Pi 


Figure  5.1;  General  Petri  net  =>  Ordinary  Petri  net 

To  show  that  the  reachability  problem  of  an  ordinary  Petri  net  is  reduci¬ 
ble  to  the  reachability  problem  in  a  STOCS  machine,  we  will  construct  an 
equivalent  STOCS  structure  from  a  given  Petri  Net  structure.  The  structures 
are  equivalent  in  the  sense  that  any  configuration  that  is  reachable  in  one 
structure  is  also  reachable  in  the  other.  We  also  require  that  the  structure  of 


76 


the  STOCS  model  is  no  bigger  than  a  constant  multiple  of  the  size  of  Petri 
net.  A  single  Petri  net  has  multiple  STOCS  representations,  each  correspond¬ 
ing  to  different  uvit  assignments.  A  unit  assignment  is  a  mapping  from  the  set 
of  places  in  Petri  nets  to  the  set  of  natural  numbers  representing  the  vnit 
numbers.  Intuitively,  each  place  in  a  Petri  net  is  assigned  to  a  process.  A  unit 
assignment  is  called  consistent  if  no  two  places  which  are  input  (output)  to  the 
same  transition  have  the  same  unit  number.  This  constraint  is  required 
because  for  every  transition  in  a  STOCS  machine,  there  is  at  most  one  place 
per  unit  that  loses  (gains)  a  token.  A  trivial  consistent  unit  assignment  is  the 
one  which  assigns  every  place  a  different  number;  hence  there  always  exists  at 
least  one  consistent  unit  assignment. 

Theorem  5.1;  Reachability  problem  of  Ordinary  Petri  nets  is  reducible  in 
linear  time  to  that  of  a  STOCS  Machine. 

Proof;  (1)  Construction  of  a  S7VCS  machine  from  an  Ordinary  Petri  net 

An  ordinary  Petri  net  is  converted  to  a  STOCS  machine  as  follows. 
Every  place  in  the  Petri  net  is  also  a  place  in  the  STOCS  machine  (see  Figure 
5.2).  These  places,  however,  may  belong  to  different  units.  Let  N  be  a  Petri 
net  =  {P,T,1,0,M)  with  the  usual  meaning  of  the  notation. 

We  first  find  a  unit  assignment  function  /:P— *1,2,..A’  such  that 
V  feP  ,ri,P2eP;  (pi,P2)C/(0  v  (p„p2)CO(/)=#>/(pi)7^/(p2). 

This  condition  implies  that  places  belonging  to  the  same  unit  cannot  be 
input(outpul)  to  the  same  transition.  It  holds  trivially  if  all  places  belong  to 
different  units 
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We  define  the  STOCS  machine  S  as  the  set  of  units  where  i=l...K 
Each  unit  I’,  is  defined  as  follows: 

L' =(F„E,-,C,  A)  t  ''■here; 


•  P,  contains  all  the  places  that  are  assigned  the  unit  number  t,  and  a  *- 
place  denoted  by  sp,. 

Pi—  {peP  1  /(p)  =»}  u  {sp.} 

•  E,  contains  as  handshake  symbols  all  those  transitions  in  which  places 
belonging  to  unit  t  participate.  It  is  assumed  that  each  transition  has  a 
unique  label. 

E,={  i^T  I  3peP.,  peI{t)uO(t)} 

•  The  configuration  of  the  STOCS  machine  (C,:P,-+N)  is  the  same  as  the 
marking  function  in  the  Petri  net,  i.e. 

C,(p)=A/(p)  for  peP,, 

C,(sp,)=*. 

•  6,CP,XE,XP,.  If  a  unit  has  an  input  place  as  well  as  an  output  place 
for  a  transition,  an  arc  is  added  between  them.  If  a  unit  has  only  an 
input  place  for  a  transition  then  an  arc  is  added  between  the  input  place 
and  its  *-place.  If  a  unit  has  only  an  output  place  for  a  transition  then  an 
arc  is  added  between  its  ‘-place  and  the  output  place.  Formally, 

6i  —  {{Pj,t,Pk)  I  3<,  Pj^I{t)APk^O{t)) 

U  {(Pj,t,spi)  I  3/  Pje/(/),  ^  Pk,  P*€P,-,PteO{<)} 

U{(sp.,t,Pt)  I  3/ p*eO(0.  ^PyeP,,Pje/{/)} 

t  We  ignore  the  set  of  Snal  places  as  they  are  irrelevant  for  the  reachability  problem. 
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Pftri-nel 


STOCS 


Figure  5.2:  Petri  net  =>  STOCS  Machine  Conversion 
The  size  of  the  resulting  STOCS  machine  is  of  the  same  order  as  the  size 
of  the  Petri  net.  Also,  the  transformation  of  the  given  Petri  net  structure  can 
be  done  in  linear  time. 

Reachability  is  equivalent  in  both  structures 

We  next  show  that  any  transition  that  is  enabled  in  Petri  net  is  also  enabled  in 
the  STOCS  machine  and  vice-versa.  The  set  of  sequences  of  transitions  is 
identical  for  both  structures  because: 

(1)  Initially,  both  the  Petri  net  and  the  STOCS  machine  have  the  same 
configuration.  Note  that  while  considering  the  configuration  of  a  STOCS 
machine  we  need  only  consider  tokens  in  simple  places,  as  the  tokens  in 
*-places  do  not  change.  More  formally,  C,=A/  \fi. 

(2)  The  set  of  transitions  that  is  enabled  for  equal  configurations  is  identi¬ 
cal. 

Let  t  be  enabled  in  Petri  Net  N. 

=  >\fpel(t):  A/(p)>l  (by  definition  of  enablement). 
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We  will  show  that  t  is  also  enabled  in  the  STOCS  machine. 

Let  teE, 

=  >  Pj€l(t)DO(t].  (by  definition  of  E,) 

Case  I;  Pj€/(0 

=  >  C,(pj)>l  (by  definition  of  C,) 

=  >  /  is  enabled  in  C,. 

Case  2:  Py€0(/)  A  ^  p^€P,:Pjt€/(0 
=  >  (sp,  ,f,Pj)e<5,  (by  the  definition  of  <5,) 

=  >  /  is  enabled  in  C,  since  C,(sp,)='^, 

If  a  transition  is  enabled  in  the  STOCS  machine  then  it  is  also  enabled  in 
Petri  net  by  a  similar  argument. 

(3)  Both  machines  starling  from  equal  configurations  reach  equal 
configurations  on  taking  the  same  transition.  On  executing  the  transi¬ 
tion  t  in  Petri  net,  the  new  marking  M’  is  defined  as  follows: 
p6/(/)=^  Af(p)=A/(p)-l 
peO{t]=^ 

otherwise  M’(p)  =  M(p). 

The  configuration  in  the  STOCS  machine  can  change  only  in  units  that 
have  t  in  their  E.  By  the  definition  of  execution  in  the  STOCS  machine  if 
(Px^i,Pj)^^i  tben 

C"(p.)=C(P,)-l=Ar(p,) 
and  C(pj)~C{pj)+l=Af(pj). 

QE.D. 
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Figure  5.3:  Conversion  from  a  Petri  net  to  a  STOCS  Machine 
We  now  present  an  example  that  shows  the  conversion  of  ordinary  Petri 
nets  to  STOCS  machines.  The  Petri  net  in  Figure  5.3  is  converted  as  follows. 
We  assign  pj  and  po  same  unit  (.'j,  as  they  do  not  share  any  transition 

for  input  or  output,  is  assigned  to  U2  Corresponding  to  transition  a  we 
draw  an  arc  from  P|  to  itself  in  Since  there  is  no  input  place  for  transition 
a  in  (*2  but  an  output  place  P3,  we  draw  an  arc  from  the  *-place,  spo  to  p^.  A 
pseudo  Pascal  procedure  to  convert  a  Petri  net  to  a  STOCS  machine  is  given 


in  Figure  5.4. 
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Procedure  Petri,  to,  STOCS', 
begin 

(*  Convert  general  petri  net  to  ordinary  petri-nets  *) 

Ne\v_Pe(ri  :=  Hack(Petri);  (*  using  Hack's  construction  *) 

(*  find  a  consistent  unit  assignment  *) 

(*  returns  an  array  color[j  such  that  no  two  places 
that  share  a  transition  are  assigned  the  same  color 
Let  there  be  d  colors  *) 

Consistent.  Unit.  Assignment; 

(*  Construct  a  STOCS  with  d  units  *) 

STOCS  :=  (Ul,U2 . Ud); 

uhere  r,=(P,«^, -'A  A  ) 

(*  construct  P-'s  *) 

for  all  p,  do 

if  fo/or(p,  )=c  then  Pf;=PfUp,-  ; 

(*  for  each  unit  i  construct  a  *-place  s(i)  for  that  unit  *) 
P,;=P.Usp.; 

(*  Construct  L,  ’s  *) 
for  each  /,  do 
for  each  p,€/(t,)UO(f,)  do 
c  ;=  color(p,) 

V  ■  =  '£  M/  .; 

‘-'C-  — 

(*  Construct  6-'s  *) 

for  all  tjt  do 
for  all  p, €/(//,  )  do 
c  ;=  color(p,  ); 

if  3pje0(/j(.)  such  that  color(p,)  =  c  then 
6,-=bMPi'fk^Pj) 
else  S,:=6^U(PiJk^^Pc)y^ 
for  all  p,€0(/ji.)  do 
if  ^  Py6/(/jt)  such  that 
c:=  color(p,); 

^c-=<5fU(sPc.^,P,); 

(*  Duplicate  Marking  *) 

C(p.);=  M(p,); 

end; 

Figure  5.4:  A  Program  to  convert  a  PN  to  a  STOCS  Machine 
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Corollary  6.1  :  The  complexity  of  the  reachability  problem  for  a  STOCS 
machine  is  at  least  exponential  space. 

Proof:  This  corollary  follows  from  Theorem  3.1  and  an  earlier  result  by  Lip- 
ton  [Lipton  76]  which  shows  that  the  reachability  problem  for  Petri  Nets  is  of 
at  least  exponential  space  complexity. 

C  onversion  of  reachability  in  a  STOCS  machine  to  that  in  a  Petri  net  is 
complicated  because  a  handshake  may  occur  in  a  unit  multiple  times.  Thus  the 
conversion  provided  in  Theorem  3.1  cannot  be  reversed  to  provide  a  construc¬ 
tive  proof  of  this  Lemma.  While  converting  a  STOCS  machine  to  a  Petri  net, 
a  single  handshake  is  converted  to  transitions,  reflecting  all  possible  ways  the 
hand>hake  could  execute.  The  proof  of  the  Theorem  5.2  shows  the  procedure 
formally. 

Theorem  5.2.  The  reachability  problem  of  a  STOCS  machine  is  reducible  to 
that  of  a  FVtri  net. 

Proof: 

Let  S  =  (C,,r2...(; ).  The  Petri  Net  N  =  (P,  T,  I,  O.  M)  where 

i-=j 

The  places  in  the  Petri  net  is  the  union  of  all  the  simple  places  in  STOCS. 

•  For  each  handshake  symbol  in  the  STOCS  machine,  we  have  one  or  more 
transitions  in  Petri  net.  Let  the  handshake  a  occur  in  a  unit  i,  n,  times. 
Then  the  number  of  transitions  required  is  the  product  of  all  f?,’s.  i.e. 

T  =  {05}  where 

i«»n 

SQ\j6, 

i-ml 
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I  5n<5,  I  =1  ae^{  Tlie  above  condition  states  that  if  a  handshake 
belongs  to  a  unit  then  there  is  exactly  one  arc  from  that  unit.  That  is,  Me 
construct  a  transition  for  each  combination  of  arcs  labeled  with  that 
^handshake. 

•  ^Pk- (Pi-o^Pk)^^} 

•  0(as)=={PieP\  3p/t:  (Pt,a,P,)65} 

•  A/(p)=C,(p)  if  peP,- 

The  set  of  sequences  of  transitions  is  identical  for  both  structures  because: 

(1)  Initially,  both  the  STOCS  machine  and  the  Petri  net  have  the  same 
configuration.  Note  that  while  considering  the  configuration  of  a  STOCS 
we  need  to  consider  tokens  only  in  simple  places  as  the  tokens  in  ‘-places 
do  not  change.  Due  to  the  definition  of  M,  the  STOCS  machine  and  the 
Petri  net  initially  have  the  same  configuration. 

(2)  The  set  of  transitions  that  is  enabled  in  the  STOCS  machine  and  the 
Petri  net  for  equal  configurations  is  identical. 

Let  05  be  enabled  in  Petri  Net  N. 

=  >\fpel{as):  ^f{p)>l■ 

=  >  Ci(p)>l  (by  definition  of  /(G5)) 

=  >  05  is  enabled  in  STOCS. 

It  is  also  easily  verified  that  a  transition  enabled  in  STOCS  is  also  enabled 
in  Petri  net. 

(3)  Both  machines  started  from  equal  configurations  reach  equal 
configurations  on  taking  the  same  transition. 
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On  executing  the  transition  t  in  Petri  net,  the  new  marking  M’  is  defined 
as  follows: 

p€/(0=^  A^(p)=A/(p)-l 
peO(/)=^  ^P(p]=^l(p)-^■l 
otherwise  M'(p)  =  M(p). 

The  configuration  in  STOCS  can  change  only  in  units  that  have  t  in  their 
L.  By  definition  of  execution  in  STOCS  if  (p,,f  ,Pj)e6,  then 
C^p.)=n/^.)-l=A/'(p.) 
and  a(pj]=C(pj)+l=.\fipjl  Q.E.D. 

Figure  5.5  shows  such  a  construction.  Corresponding  to  the  handshake 
mem  in  the  STOCS  machine,  we  get  the  transitions 

and  Corresponds  to  the  handshake 

between  l\  and  C'o  the  tokens  at  pj  and  p^  whereas  the  second  mem 
corresponds  to  the  handshake  with  tokens  at  p2  and  p^.  ‘-places  are  removed. 
Figure  5.6  gives  a  procedure  written  in  pseudo  Pascal  to  convert  a  STOCS 
machine  to  a  Petri  net. 

Corollary  6.2;  The  class  of  languages  accepted  by  free  labeled  ordinary  Petri 
nets  is  identical  to  that  accepted  by  free  labeled  STOCS(FLSTOCS)  machines. 

Proof.  In  the  proof  of  Theorem  5.1,  we  assigned  a  free  labeling  to  the  Petri 
net  (the  reachability  problem  in  Petri  net  is  independent  of  its  labeling).  The 
resulting  STOCS  machine  accepted  the  same  language  as  that  accepted  by  the 
Petri  net.  In  the  proof  of  Theorem  5.2,  the  number  of  instances  of  each 
handshake  is  exactly  one  if  the  STOCS  machine  is  free  labeled.  The  Petri  net 
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Figure  5.5;  Petri  Net  for  2-oul-of-3  problem 
constructed  out  of  the  STOCS  machine  has  the  same  language.  From  these 
two  Theorems,  it  can  be  concluded  that  the  class  of  languages  accepted  by 
FLOPN  and  FLSTOCS  machines  is  identical.  Q.E.D. 
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Procedure  STOCS.to.Pelri{); 
begin 

(*  Cou struct  P  *) 

P  :=  UP.-sp, 

t 

(*  Construct  T  *} 

T  :=  {05  I  u'hereCQ\^6i,  such  that  \  5n6,  I  =1  V/ 1 } 

(*  Construct  I(ac;)  *) 

I{as)={pieP\  Bpi,:  {Pi^a,Pk)^S} 

(*  Construct  0(ag)  *) 

0(as]={PieP\  Bpi,:  (pk^o^P,)cS} 

(*  Marking  *) 

A!(p)=Ci(p)  ifpeP,- 

end 

Figure  5.6;  A  Procedure  to  Convert  a  STOCS  machine  to  a  PN 

2.1.  Decomposition  of  a  Petri  net:  Consistent  Unit  Assignment 

.As  mentioned  earlier,  a  Petri  net  has  multiple  equivalent  STOCS 
machines  depending  on  different  unit  assignments.  In  our  proof  of  Theorem 

5.1.  ^ve  used  the  trivial  consistent  unit  assignment  -  assignment  of  each  place 
to  a  different  process.  This  assignment  may  result  in  a  large  number  of  units 
and  the  resulting  STOCS  may  not  be  easy  to  understand.  For  example,  Figure 
5.3  shows  a  Petri  net  and  its  equivalent  STOCS  machine.  The  alternative 
machine  shown  in  Figure  5.7  is  more  difficult  to  understand  and  has  more  *- 
places  than  the  machine  in  Figure  5.3. 

Since  each  unit  represents  a  completely  independent  entity,  a  reasonable 
measure  of  complexity  of  a  STOCS  machine  is  the  number  of  units  it  contains. 
With  this  motivation,  it  is  useful  to  convert  a  Petri  net  into  a  STOCS  machine 
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Figure  5.7;  An  alternate  STOCS  machine  for  Petri  net  in  Figure  5.3 
such  that  the  number  of  units  is  minimized.  We  first  show  that  the  problem  of 
finding  a  consistent  unit  assignment  such  that  the  number  of  units  in  the 
resulting  STOCS  machine  is  minimum  is  NT-complete  [Garey  79].  More  for¬ 
mally. 

Theorem  5.3;  The  following  problem  is  NP-complete. 

Jimtance:  An  ordinary  unmarked  Petri  net  N  =  (P,T4>0)  and  a  positive 
number  K  <=  I P I . 

Question:  Is  Petri  net  N,  K-decomposable,  i.e.  is  there  a  function 
/:P— *{1,2...A’ }  such  that 

V/C  (Pi,P2)^^(0''IPl-P2)^^(0=^/(Pl)7^/(P2)- 

Proof: 

(a)  It  is  in  A'P. 

This  is  immediate  as  there  is  a  succinct  certificate  of  K-decomposability  -  the 
consistent  unit  assignment  function.  In  other  words,  a  Turing  machine  can 
non-deterministically  guess  the  unit  assignment  function  and  proceed  to  verify 
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that  it  is  consisleni 


(b)  Reduction  from  vertex  coloring  to  K-decomposability. 

Let  there  be  a  graph  G=(\’,E).  We  construct  a  Petri  net  N  from  it  as  follows: 
N  =  (P,T.I,0)  whore 

P  =  \ 

T  =  E 

I(t)  =  {(rl,r2)  I  /=(r,.r2)} 

0(t)  =  0 

Assume  that  this  Petri  net  is  K-decomposable.  This  implies  that  there  exists  a 
function  f;\'-> {1,2,..K}  such  that 

This  condition  is  identical  for  K-coloring  of  the  original  graph.  Therefore,  it 
follows  that  N  is  K-decumposable  iff  G  is  k-colorable.  Q.E.D. 

The  above  proof  shows  how  K-colorability  can  be  transformed  into  K- 
docornposability.  Figure  5.8(a)  illustrates  this. 

^^'e  next  sho^^  that  K-decomposability  of  a  Petri  net  can  be  reduced  in 
linear  time  to  K-colorability  of  a  graph.  Therefore,  we  can  use  any  algorithm 
that  returns  good  sub-optimal  coloring  or  optimal  coloring  with  good  probabil¬ 
ity  to  solve  K-decomposability  problem. 

Theorem  6.4:  K-decomposability  of  a  Petri  net  can  be  reduced  to  K- 
colorability  of  a  graph. 

Proof:  W  e  construct  a  graph  G  =  (^^E)  as  follows. 
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Petri-net 


pi  p2  p3  pi  P2 


Figure  5.8:  K-decomposability  <  =  >  K-coIorability 
V  =  P,  the  set  of  places 

E=  {(t’l-i’o)  13/  C/(/)r{i;„t'2}CO(/)} 

Clearly,  if  there  exists  a  K-color  assignment  to  the  graph,  the  original  Petri 
net  is  K-decomposable. 

Figure  5.8(b)  shows  a  conversion  from  K-decomposability  of  a  Petri  net  to 
K-colorability  of  a  graph.  Note  the  conversion  of  an  ordinary  Petri  net  such 
that  each  transition  has  exactly  one  input  and  one  ouput.  Such  a  Petri  net  is 
equivalent  to  a  finite  state  machine.  When  such  a  Petri  net  is  converted  to  a 
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STOCS  machine,  a  single  unit  is  enough  as  consistency  conditions  are  always 
satisfied.  The  reduction  is  pleasant  as  it  gives  us  back  the  classical  finite  state 
machine.  Another  observation  is  that  any  unit  without  ^-places  is  just  an  S- 
invariant  of  the  original  Petri  net  [Murata  84].  Thus,  a  Petri  net  can  always  be 
decomposed  into  S-invariants  and  units  with  *-places. 

3.  Connparison  of  Ease  in  Modeling 

Having  compared  the  inherent  power  of  both  models,  we  now  compare 
the  convenience  of  modeling  in  them.  Petri  nets  have  been  used  to  model  a 
large  variety  of  systems  such  as  computer  hardware,  computer  software, 
PERT,  chemical  equations  and  communication  protocols.  Our  aim  is  to 
analyze  concurrent  systems  and  we  will  limit  our  discussion  accordingly.  We 
further  constrain  our  modeling  to  systems  that  use  synchronous  messages.  We 
believe  that  concurrent  systems  with  synchronous  messages  are  easier  to  model 
using  STOCS  machines  than  Petri  nets  for  the  following  reasons: 

1)  The  STOCS  model  is  closer  to  programming  languages. 

Once  a  concurrent  system  has  been  specified  in  a  concurrent  model,  it 
needs  to  be  implemented  in  some  programming  language  by  filling  the  details 
missing  in  the  high-level  specification.  It  is  easier  to  derive  an  implementation 
from  a  model  that  is  closer  to  a  programming  language.  The  STOCS  model  is 
closer  to  most  concurrent  programming  languages  than  a  Petri  net  is.  hfost 
concurrent  programming  languages  use  synchronous  communication  which  is 
closer  to  the  semantics  of  a  handshake  in  STOCS.  Specifically,  rendezvous  of 
Ada  and  I/O  statement  of  CSP  can  be  easily  represented  in  the  STOCS 
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model.  The  STOCS  machine  also  has  the  notion  of  process(unil)  which  is  miss¬ 
ing  in  Petri  nets.  As  a  result  of  this  closeness  to  programming  languages,  we 
have  incorporated  the  STOCS  formalism  in  C  to  make  it  suitable  for  con¬ 
current  programming.  This  aspect  of  the  STOCS  model  is  discussed  further  in 
Chapter  8. 

2)  Petri  nets  require  an  explicit  specification  of  interaction  between 
multiple  processes. 

The  disadvantage  of  Petri  net’s  style  of  modeling  is  that  a  net  can  become 
very  complicated  because  places  belonging  to  different  processes  get  inter¬ 
mixed.  The  implicit  interaction  between  processes  based  on  the  name  of 
interaction  promotes  modularity  in  the  specification  of  the  system.  For  exam¬ 
ple,  consider  the  2-out-of-3  problem.  Since  an  explicit  interaction  is  required, 
we  need  to  have  explicit  arrows  between  transitions  and  places  belonging  to 
the  memory  scheduler  and  processes  requesting  memory  blocks.  The 
equivalent  STOCS  machine  as  shown  in  Figure  5.5  is  much  simpler. 

3)  Partial  specification  is  difficult  in  Petri  nets. 

This  is  the  major  disadvantage  of  Petri  nets  compared  to  STOCS 
machines.  Since  there  is  no  notion  of  communication  between  multiple  Petri 
nets,  the  behavior  of  a  system  is  generally  specified  by  one  big  Petri  net.  This 
makes  specification  of  the  system  difficult  to  understand  and  write.  As  another 
consequence,  the  system  has  to  be  specified  completely  before  it  can  be 
analyzed.  To  appreciate  this,  consider  the  example  of  job  scheduling  discussed 
in  Section  4.1  in  Chapter  3.  Figure  3.11  shows  a  Petri  net  for  the  shop  and 
Figure  3.12  shows  a  STOCS  machine  for  it.  In  the  STOCS  model,  order, 
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operators  and  machines  are  specified  separately.  As  a  result,  it  is  easier  to  add 
another  order,  machine  or  operator  to  the  STOCS  machine  than  to  the  Petri 
net. 

Sometimes,  the  communication  between  various  Petri  nets  is  represented 
using  tokens.  Each  Petri  net  is  considered  to  bave  input  and  output  places. 
Two  processes  are  composed  by  overlapping  the  output  of  one  with  the  input 
of  the  other.  This  way  of  communication  is  more  suitable  for  asynchronous 
messages  and  cannot  represent  synchronous  events. 

4)  STOCS  machines  have  a  closer  correspondence  with  state 
machines. 

Each  unit  in  a  STOCS  machine  can  be  thought  of  as  a  generalized  finite 
state  machine.  Since  the  notion  of  state  arises  in  many  contexts,  it  is  easier  to 
write  specifications  in  the  STOCS  model  than  in  Petri  nets.  Each  token  in  a 
unit  roughly  corresponds  to  the  current  state  of  a  finite  state  machine  it  is 
simulating.  Consider  again  the  example  of  shop  modeling.  Each  machine  and 
operator  has  a  finite  number  of  states  and  is  easily  modeled  as  a  finite  state 
machine. 

5)  Languages  accepted  by  STOCS  have  an  algebraic  characteriza¬ 
tion 

As  shown  in  Chapter  4,  the  language  accepted  by  a  STOCS  machine  can 
be  characterized  by  a  concurrent  regular  expression.  These  expressions  are 
built  of  algebraic  operations  on  strings  and  form  a  suitable  basis  for  specifying 
many  concurrent  systems.  Chapter  4  provides  examples  of  concurrent  systems 
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which  are  easier  to  model  algebraically.  The  duality  between  STOCS 
machines  and  concurrent  regular  expressions  is  therefore  useful  for  choosing 
the  appropriate  specification  for  any  domain. 


To  illustrate  our  arguments,  consider  the  producer  consumer  problem. 
The  solution  to  the  problem  expressed  in  the  STOCS  model  and  Petri  nets  is 
shown  in  Figure  5.6.  Note  the  following  advantages  of  STOCS  model  over 
Petri  nets. 


(b) 


Producer 


product 


get,  it  cm 


Buffer 


L\ 


g(i_i(cm 


('3 

«6 


get_iicm 


Consumer 

t'3 


*5 

get,  it  cm 


Figure  5.6;  A  Petri  net  and  a  STOCS  machine  for  producer  consumer  problem 
1)  The  Petri  net  representation  consists  of  one  single  Petri  net  for  the  pro¬ 
ducer,  the  consumer  and  the  buffer. 
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2)  The  unbounded  version  is  exactly  analogous  to  the  bounded  version  for 
STOC.S(*  tokens  instead  of  n).  This  is  not  true  for  the  Petri  net. 

3}  It  is  easier  to  specify  each  component  of  the  system  separately.  For  exam¬ 
ple,  ;the  behavior  of  the  producer  process  is  simply  modeled  as  (produce 
put.  buffer)*. 

4.  Comparison  of  Languages 

.A.  Petri  Net  can  be  defined  as  a  four  tuple  (P,T,I,0)  where  P  stands  for 
the  set  of  places.  T  stands  for  the  set  of  transitions,  I  stands  for  the  set  of 
input  arcs  and  O  for  the  output  arcs.  In  addition,  we  also  define  a  labeling 
function  where  E  is  the  alphabet  of  the  Petri  Net.  We  also  define  an 

initial  marking  //(,  which  assigns  a  certain  number  of  ’’tokens”  to  places.  The 
function  b  is  a  trsmformstion  function  which  associates  a  marking  and  a 
sequence  of  transition  firings  to  a  new  marking.  Depending  on  the  acceptance 
criteria  four  different  types  of  languages  for  Petri  Nets  have  been  defined 
[Peterson  81].  These  languages  are  called  L.G,T  and  P-type  languages.  The 
acceptance  criteria  for  a  L-type  language  is  that  the  Petri  Net  should  start 
from  the  initial  configuration  and  reach  one  of  the  predefined  final 
configurations.  In  G-type  languages  the  final  configuration  should  cover  at 
least  one  final  configuration.  A  T-type  language  is  accepted  if  the  Petri  Net 
reaches  a  terminal  configuration  i.e.,  a  configuration  where  all  transitions  are 
disabled.  A  P-type  language  is  a  L-type  language  where  all  reachable 
configurations  are  final  configurations  i.e,  e=a(/3)  is  accepted  if  S(f/Q,d)  is 
defined. 
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In  addition  to  these  classes  of  Petri  Net  languages,  v>e  define  a  new  class 
of  languages  called  F-type  Languages.  The  definition  of  F-type  languages  is  as 
foDows.  A  Language  L  is  a  F-type  Petri  net  language  if  there  exists  a  Petri  net 
structure  (P,T,LO),  a  free  labeling  of  the  transitions  ciT— »E,  an  initial  mark¬ 
ing  //q  and  a. set  of  final  states  F  such  that  L  =  {<t(s)6E*  I  seT*  and  the  mark¬ 
ing  ^J=6{ftQ.s)  has  no  tokens  in  any  place  €(F— /')}.  In  this  dissertation,  a  Petri 
net  language  would  always  mean  an  F-type  language. 
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Figure  5.1:  A  STOCS  machine  accepting 
Theorem  5.5:  All  concurrent  regular  languages  are  also  Petri  net  languages. 

Proof:  From  the  construction  of  Theorem  5.2.  For  any  STOCS,  the  Petri  net 
constructed  has  the  same  language  as  the  STOCS  machine. 

The  above  result  also  tell  us  that  there  exist  context-free  languages  which 
are  not  Petri  net  languages  and  therefore  not  concurrent  regular.  An  example 
of  such  a  language  is  {u’tv^}  which  can  not  be  accepted  by  a  Petri  net  (Peter- 
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son  81].  Figure  5.7  demonstrates  that  there  are  concurrent  languages  that  are 
not  context-free.  The  language  accepted  by  the  STOCS  machine  in  Figure  5.7 
is  L=  {o''6"c”  I  »J>0)  which  is  not  context  free.  Since  the  machine  is  deter¬ 
ministic,  we  have  shown  that  there  are  DSTOCS  languages  that  are  not  con¬ 
text  free  either. 


CS;  Context-sensitive  CR:  Concurrent  regular 

CF:  Context-free  U  :  Unit  languages 

PN;  Petri  net  languages  R:  Regular 

Figure  5.8;  Relation  of  Concurrent  Regular  Languages  with  other  classes 

Since  concurrent  regular  languages  are  included  in  Petri  net  languages, 
wliich  are  properly  included  in  context  sensitive  languages,  we  conclude  that 
concurrent  regular  languages  are  properly  included  in  context  sensitive 
languages.  Figure  5.8  shows  the  relationship  of  various  classes  of  languages  by 
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a  \'enn  diagram. 

Theorem  5.4  also  provides  us  a  method  of  characterizing  the  language  of 
ordinary  Petri  nets  by  means  of  algebraic  expressions.  Concurrent  regular 
expressions  defined  so  far  characterize  the  class  of  languages  of  STOCS 
machines.  However,  the  class  of  language  of  STOCS  machines  is  a  proper  sub¬ 
set  of  that  accepted  by  Petri  nets.  Since  any  free  labeled  ordinary  Petri  net  is 
characterized  by  a  concurrent  regular  expression,  an  ordinary  Petri  net  can  be 
described  by  extending  CRE's  with  the  substitution  operator. 

A  substitution  operator  denoted  by  <i:y>  replaces  every  occurrence  of 
X  by  y.  For  example.  ab*c  <Cc:a  >  is  the  same  as  Qb*a.  An  extended  con¬ 
current  regular  expression  (ECRE)  over  E  is  defined  as  follows. 

Definition:  A  unit  expression  is  an  ECRE.  If  A  and  B  are  ECRE's  then  so  are 
A+BA.B,A\\B,A []B,and.4  <A':y>. 

Theorem  6.6:  The  language  accepted  by  ordinary  Petri  nets  without  t  is  the 
same  as  that  characterized  by  an  ECRE  under  our  acceptance  condition. 

Proof: 

1)  Petri  Net  =>  ECRE 

Convert  the  Petri  net  P  to  a  free  labeled  Petri  net  P’  by  assigning  a  substitu¬ 
tion  <X:'^'>.  By  Theorem  3.2,  the  language  of  P’  is  the  same  as  that  of  a 
STOCS  machine  S.  By  Theorem  4.5,  the  language  of  a  STOCS  machine  is  the 
same  as  that  of  a  CRE  C.  Then 

L(P)  =  L(P')<Y:X>  =  L(CRE)<X:Y>  =  L(CRE<X:Y>) 
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2)  ECRE  =>  Petri  Net 


Every  unit  expression  can  be  converted  to  a  Petri  net  by  Theorem  3.2  and  4.5. 
Petri  nets  are  closed  under  choice,  concatenation,  interleaving,  substitution 
and  sy  nchronous  composition,  and  therefore  the  result.  Q.E.D. 

5.  Conclusions 

In  this  chapter,  we  have  shown  that  the  reachability  problem  is  equivalent 
for  STOCS  machines  and  Petri  nets.  This  provides  us  the  confidence  in  model¬ 
ing  capabilities  of  STOCS  machines,  because  any  system  that  can  be  modeled 
as  configurations  of  a  Petri  net  can  equivalently  be  modeled  by  a  STOCS 
machine.  We  have  also  shown  that  STOCS  machines  offer  many  advantages 
over  Petri  nets  for  modeling  concurrent  systems  based  on  synchronous  com¬ 
munication. 
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CHAPTER  6 


STOCS  Machines  With  Uncontrollable  Event 


1.  Introduction 

In  this  chapter,  v>e  provide  an  exlensional  theory  of  concurrent  processes 
that  may  have  uncontrollable  events.  These  events  are  not  observable  by  the 
environment  and  their  execution  depends  entirely  on  the  process.  To  provide 
the  e.vtensional  theory  of  such  processes,  we  retain  our  previous  notion  of 
equivalence,  i.e.  two  concurrent  systems  are  equivalent  if  and  only  if  the 
observer  cannot  di<;tinguish  between  them  by  supplying  an  input  string  and 
observing  whether  they  accept  it.  However,  we  now  assume,  that  for  a  given 
string,  a  system  may  sometimes  accept  it  and  sometimes  reject  it.  This 
assumption  is  different  from  that  made  in  classical  formal  languge  theory, 
which  requires  a  machine  to  either  always  accept  a  string  or  always  reject  it. 
In  concurrent  systems,  and  more  generally  in  nature,  there  exists  an  uncer¬ 
tainty  in  execution  which  implies  that  any  given  string  may  sometimes  be 
accepted  and  sometimei)  rejected.  Example  of  such  scenarios  are  as  follows: 

(1)  Timeout;  A  process  may  change  its  internal  state  on  timeout  and  events 
which  were  valid  earlier  may  not  be  so  any  more.  For  example,  consider  an 
elevator  in  a  building  with  three  floors.  If  a  passanger  enters  the  elevator  on 
the  second  floor,  he  can  press  the  button  for  either  floor  1,  or  floor  3.  However, 
if  he  docs  not  do  so  within  some  time,  the  elevator  does  a  timeout  and  starts 
going  down.  In  this  state  it  will  satisfy  request  only  for  floor  1.  The  behavior  of 
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the  elevator  is  shown  in  Figure  6.1(a).  Consider  an  alternative  design  of  the 
elevator  which  does  not  timeout.  This  elevator  E'  is  shown  in  Figure  6.1(b). 
By  the  semantics  of  classical  finite  state  machine  theory,  the  finite  state 
machines  corresponding  to  two  designs  of  of  the  elevators  are  equivalent 
because  they  accept  the  same  language.  According  to  our  semantics,  these 
machines  will  be  treated  different  because  the  first  one  may  reject  a  request  for 
the  third  floor,  whereas  the  second  one  cannot. 


E  E- 


/ 


floorl 

\_ 

f 

Figure  6.1:  Two  Different  Elevators 

(2)  Random:  A  process  may  use  randomness  and  change  its  state  on  its  own 
For  example,  consider  a  double-or-nothing  game.  .Assume  that  you  toss  a  fair 
coin,  and  depending  on  its  result,  you  win  or  lose.  Consider  a  second  game  in 
which  you  know  how  to  toss  the  coin  to  get  the  desired  side.  In  this  game  you 
have  the  choice  of  winning  or  losing.  Both  situations  are  shown  in  the  Figure 
6.2.  The  classical  finite  slate  machine  semantics  do  not  differentiate  between 
the  two  cases  as  the  language  acceptable  in  either  case,  is  {toes. head, 
toBB.tail).  \N’ith  our  semantics,  the  first  machine  A/,  has  randomness  and 
may  accept  or  reject  both  head  and  tail  depending  on  which  r  the  machine 


takes.  In  contrast,  A/o  does  not  reject  any  of  them  (i.e.,  the  coin’s  outcome  is 
dictated  by  its  environment  ). 


Ml  M2 


Figure  6.2;  Controllable  and  Uncontrollable  Toss 


(3)  Internal  Faults:  The  machine  may  make  internal  state  change  due  to  a 
fault.  A  fault  could  be  any  unanticipated  event  for  a  process  -  such  as  an  error 
in  disk  writing,  opening  a  file,  and  termination  of  the  communicating  process. 
The  modeling  of  such  situations  requires  the  use  of  uncontrollable  events. 

(4)  Hidden  Events:  For  abstraction  purposes,  we  may  chose  to  call  certain 
events  in  a  process,  internal.  These  events  can  be  executed  by  the  machine  on 
its  own  will.  Consider  for  example,  a  passanger  who  chooses  to  take  either  a 
train  or  a  bus  based  on  some  complex  reasoning.  For  the  analysis  this  reason¬ 
ing  may  be  irrelevant  and  therefore  we  will  represent  the  external  behavior  as 
shown  in  the  Figure  6.3. 

With  the  motivation  provided  above,  we  allow  a  machine  to  take  some 
unobservable  actions.  These  actions,  however,  must  terminate,  and  we  con¬ 
sider  any  machine  that  can  engage  in  unobservable  actions  in  an  unbounded 
manner  an  invalid  machine.  A  machine,  when  offered  a  choice  of  events  can 
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Figure  6.3.  Use  of  r  Symbols  for  Abstraction 
reject  the  experiment  if  and  only  if  it  cannot  participate  in  any  event  or  take 
any  internal  action. 

This  chapter  is  organized  as  follows.  Section  2  compares  our  framework 
for  hidden  events  with  that  proposed  by  Milner  and  Hoare[Nfilner  80,  Hoare 
85].  Section  3  describes  the  semantics  of  uncontrollable  STOCS  machines. 
Section  4  describes  the  semantics  of  uncontrollable  concurrent  regular 
processes.  Section  5  proves  that  the  equivalence  of  the  STOCS  model  and 
CRE  holds  even  when  the  uncontrollable  actions  are  incorporated  in  the  sys¬ 
tem. 

2.  Related  Work 

Uncontrollable  actions  have  also  been  modeled  and  analyzed  by  CCS  and 
CSF.  Our  work  differs  from  them  in  following: 

Automata  Theoretic  Equivalence 
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CCS  and  CSP  are  algebraic  systems  and  they  do  not  have  any  equivalent 
notions  in  automata  theory.  Whereas  our  theory  has  useful  operators  such  as 
Kleene  closure  required  to  define  finite  state  processes,  such  operators  are  miss¬ 
ing  in  both  CCS  and  CSP. 

Prefix  Properly 

Both  CCS  and  C.SP  satisfy  the  prefix  property,  that  is,  if  a  sequence  of 
event  is  acceptable  then  all  its  prefixes  are  also  acceptable  to  the  system.  Our 
framework  is  more  general  as  it  can  model  situations  in  \vhich  the  prefix  pro¬ 
perly  may  not  hold.  If  we  do  want  the  prefix  property,  then  we  can  easily 
simulate  it  by  considering  all  places  final. 

Separation  of  Specification  and  Operational  on -determinism 

Classical  non-del erministic  finite  state  machines  provide  non-determinism 
during  the  specification  of  the  system.  This  leads  to  a  compact  description  of 
the  system.  During  the  operation,  there  is  only  oracular  non-determinism  as  it 
is  assumed  that  the  machines  make  a  correct  guess  at  each  choice  presented. 
Such  non-determinism  also  arises  due  to  e  arcs  in  finite  state  machines,  which 
has  the  semantics  that  the  finite  state  machine  takes  that  arc  if  it  can  lead  to 
acceptance  of  the  string. 

On  the  other  hand,  CCS  and  CSP  provide  demonic  non-determinism  at 
the  operation  level,  which  we  call  unconlrollability.  The  user  cannot  specify 
that  a  process  must  take  the  choice  which  is  the  best  for  that  string.  If  there 
are  multiple  choices  that  are  compatible  with  the  environment  the  process  can 
make  any  of  the  choices,  r  represents  an  internal  action  and  the  process  can 
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take  this  action  ^^■henever  it  desires  so.  Even  though  this  approach  can  model 
situations  not  possible  in  classical  6nile  state  machines  (as  shown  in  Section 
6.1).  it  loses  the  compactness  of  the  non-deterministic  finite  state  machines.  In 
our  theory,  we  have  both  kinds  of  non-determinism.  7  provides  operational 
non-determinism  and  we  call  it  uncontrollability,  e  and  multiple  symbols  on  a 
single  state  provide  non-determinism  at  the  specification  level. 

3.  Uncontrollable  STOCS  Machines  (STOCS  with  r) 

To  describe  our  model  extended  with  hidden  operations,  we  first  describe 
the  valid  syntactical  structures  expressed  in  our  formalism  and  then  describe 
their  denotational  semantics. 

3.1.  Syntax 

A  USTOC'S  (Uncontrollable  STOCS)  machine  M  is  a  set  of  units 
Each  unit  is  a  five  tuple  i.e.  U,  =  (F,.C,,i;,,5,,F,)  where: 

•  P,  is  a  finite  set  of  places 

•  C\  is  an  initial  configuration  which  is  a  function  from  the  set  of  places  to 

nonnegative  integers  A'  and  a  special  symbol  i.e.,C,:F,— ►(.Vu{  *}) 

•  E,-  is  a  finite  set  of  handshake  labels 

•  (3,CP,xE,U{f,f{xF,, 

•  F,  is  a  set  of  final  places,  F,  CP,. 

The  above  definition  is  the  same  as  that  of  a  STOCS  machine  except  that  an 
arc  can  be  labeled  by  any  of  the  events  in  the  alphabet  set  or  by  an  c  or  a  r 
symbol.  We  describe  these  symbols  next. 
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€:  This  symbol  has  the  same  semantics  as  in  classical  automata  theory.  It 
provides  non-determinism  in  the  specification  of  a  system.  From  an  opera¬ 
tional  view,  we  say  that  a  machine  consults  an  oracle  if  it  has  multiple 
choice. 

r.  This  symbol  stands  for  some  internal  action  by  a  machine.  The  external 
environment  has  no  control  over  this  action.  This  symbol  can  be  used  by 
a  machine  to  make  an  internal  choice.  The  internal  action  is  treated  like 
an  algorithm  which  must  terminate.  This  symbol  provides  non¬ 
determinism  during  the  operation  of  the  machine. 

For  simplicity,  we  chose  to  disallow  the  case  when  the  machine  does  not 
terminate  on  the  given  input  by  going  through  a  loop  of  internal  actions.  Since 
in  real  life,  we  would  not  like  to  have  such  machines  we  consider  only  those 
machines  syntactically  valid  which  do  not  have  a  loop  of  internal  actions.  In 
other  words,  we  do  not  allow  any  unit  that  has  a  cycle  consisting  entirely  of  r 
symbols.  Figure  6.4  shows  such  a  unit. 

This  restriction  is  for  clarity  and  can  be  easily  removed  by  providing 
semantics  to  the  processes  that  can  loop  on  internal  actions.  To  add  such 
semantics,  it  would  be  necessary  to  add  the  notion  of  divergence  set  (Hoare  85] 
which  is  the  set  of  strings  that  can  lead  the  machine  into  a  nonterminating 
computation. 

With  this  additional  constraint  on  the  validity  of  a  system,  we  can  assume 
that  given  a  string  a  machine  always  terminates. 
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Figure  6.4:  A  Syntactically  Invalid  Machine 

3.2.  Semantics 

In  our  earlier  discussion,  we  had  assumed  that  STOCS  machines  did  not 
have  7  symbols.  The  semantics  of  such  a  machine  was  defined  as  a  tuple  of  its 
alphabet  and  its  acceptance  language.  As  we  saw  in  our  previous  example, 
these  two  sets  may  not  characterize  a  USTOCS  machine  completely.  The 
semantics  of  a  STOCS  machine  with  r  is  defined  as  the  triple  [E,maxL.miiiL) 
where: 

(1)  (Symbol  Set):  It  is  the  set  of  symbols  for  the  machine.  For  example,  the 
set  of  symbols  for  the  machine  Ml  is  {floorl,  floorS). 

(2)  maxL  (Optimistic  Acceptance  Set):  It  is  the  set  of  strings  that  can  be 
accepted  by  the  machine.  This  is  the  conventional  trace  defined  for  a  non- 
deterministic  finite  stale  machine.  Thus  a  string  s  is  acceptable  if  and  only  if 
there  exists  a  way  of  accepting  the  string  s.  At  each  node  the  machine  chooses 
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any  of  the  choices  afforded  to  it.  A  ris  identical  to  an  <  for  this  set.  For  exam¬ 
ple,  the  optimistic  acceptance  set  for  both  machines  E  and  E’  is  {floorl, 
floors}. 

(3)  rhinL  (Pessimistic  Acceptance  Set);  It  is  the  set  of  strings  which  are  always 
accepted.  We  assume  that  the  machine  can  take  an  internal  action  whenever  it 
desires  so.  Therefore,  at  each  stage  of  decision,  the  machine  can  either  make 
an  oracular  guess  or  take  an  internal  action.  If  there  are  multiple  internal 
actions  (multiple  outgoing  r  arcs),  the  machine  may  choose  any  of  them. 

For  example,  the  minimum  acceptance  set  for  E  is  {floorl}  while  for  E‘  it 
is  {floorl,  floors}. 

Example 

The  semantics  function  S  for  A/j  in  Figure  6.1  is 

5[|E1]=  {(floor  I,  fioor3),{  floor  I,  floorZ),{  floorl)} 
and  for  E’,  it  is 

.SHE'D  =  {(floor!, floors), (floorl.floorZ), (floorl, floorZ)} 

Similarly,  the  semantics  functions  for  Afj  and  A/o  in  Figure  6.2  are 

S(1A/jD=  {(toss, /lead, fail), (foss.h€ad,(os$. tail ),()} 

5[[A/2]]=  {(toss , head , fail  ),{toss. head  ytoss.tail), (toss. head , toss. tail)} 

We  next  show  that  the  minimum  acceptance  set  is  the  same  as  the  set  of 
strings  that  must  be  accepted  by  the  machine  if  at  each  of  the  node  machine 
choses  an  internal  action  if  possible. 

Definition;  The  lav-acceptance  set  of  a  USTOCS  machine  is  the  set  of  strings 
traced  by  tokens  such  that  if  a  token  reaches  a  place  with  one  or  more  out- 
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going  arcs  labeled  r  then  il  can  only  take  one  of  them. 

Theorem  6.1:  The  minimum  acceptance  set  of  a  USTOCS  machine  is  the 
same  as  the  tau*acceptance  set. 

Proof;  By  the  definition  of  minimum  acceptance  set,  minL  C  tau-acceptance 
set.  Let  a  string  belong  to  tau-acceptance  set.  We  v\ill  show  that  this  string 
cannot  be  rejected.  At  each  point  during  the  simulation  of  machine,  il  may 
either  make  an  oracular  guess  or  or  take  a  r  action.  Since  on  taking  r,  the 
string  gets  accepted,  the  machine  always  take  a  t  action.  Therefore,  the  string 
also  belongs  to  the  min-acceptance  set.  Q.E.D. 


Figure  6.5:  Equivalent  Structures  for  minL 

Theorem  6.1  provides  us  an  easy  way  to  calculate  the  minL  for  a 
USTOCS  machine.  For  all  places  with  t  as  out-going  edges,  we  delete  non-tau 
edges  as  they  can  never  be  taken  for  minL.  The  resulting  USTOCS  machine 
will  have  two  types  of  places  -  ones  with  out-going  arcs  labeled  as  r  and  others 
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with  out-going  edges  labeled  with  epsilon  or  labels  from  E.  By  Theorem  6.1, 
the  minL  of  both  machines  is  identical.  For  examples,  to  evaluate  the  minL  of 
the  machine  in  Figure  6.5(a),  it  is  sufficient  to  evaluate  the  minL  of  the 
machine  in  Figure  6.5(b). 

4.  Uncontrollable  CRE  (UCRE) 

4.1.  Syntax  of  Uncontrollable  Concurrent  Regular  Expressions 

We  add  an  additional  operator  for  the  semantics  of  t.  This  operator  is 
termed  non-del eriv in istic  or  by  Hoare.  We  chose  to  call  this  operator  uncon¬ 
trollable  choice  and  denote  it  by 

<regular>  ::  <symbol>  I  <regular>*  1  <regular>.<regular>  I 
<regular>  -f  <regular>  I  <regular>  ®  <regular> 

<unit>  ::  <regular>  I  <unit>  ||  <unit>  I  <unit>‘* 
<concurrent.regular>  ::  <unit>  I 

<concurrent.regular>  []  <concurrent. regular > 

4.2.  Semantics  of  Concurrent  Regular  Expressions 

If  concurrent  regular  expressions  are  to  characterize  USTOCS  machines, 
their  semantics  must  also  be  specified  as  a  triple  {^,maxL,minL).  The  new 
operator,  uncontrollable  choice,  is  identical  to  ordinary  choice  for  the  purposes 
of  maxL  but  different  for  minL.  Consider  the  expressions  (a-l-b)  and  (a  ^  b). 
Both  of  them  accept  the  language  {a,b}.  However  it  is  possible  that  (a  0  b) 
not  accept  a  or  b,  whereas  a-l-b  will  always  do  so. 
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With  the  above  intuition,  we  formally  define  the  semantics  of  concurrent 
reguli-.r  expressions  as  follows: 

Primitive  Regular  Expressions; 

S|i<ll  = 

■S(l“ll  =  VoeE 

Controllable  Choice: 

Uncontrollable  Choice; 

This  operator  is  responsible  for  the  differences  between  the  maximum  and 
minimum  language. 

S\\AirB\]  =  {!:.4Ui:B.O(.4)UO(B),P(.4)nF(J3)} 

Concatenation; 

5p,e||  =  {Z^UZb.O^Ob.P^.Pb) 

Kleene-Closure: 

511.4*1]  = 

Interleaving: 

si|,4|ii?|i  =  {!:^uSb.o^I10b.f^1|Pb) 

Alpha-Closure: 

Synchronous  Composition; 
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511.411B11  =  {S^USb.O^OOb.P^OPb! 

Example  1:  Assume  that  we  need  to  model  the  fact  that  the  machine  must 
chose  a  but  after  that  it  may  accept  6  as  well  as  c. 

5l|fl.(6+c)|)  =  {(a,6,r),(a6,ac),(a6,oc)} 

On  the  other  hand,  if  the  machine  is  such  that  after  executing  a,  it  may 
accept  b  or  c,  but  also  reject  either  of  them.  Then, 

5[|o.(6^c)l]  =  {(a,6.r).(a6,of ),()} 

Example  2:  We  now  give  the  semantic  functions  of  some  non-trivia)  exam¬ 
ples. 

5[|(flc-t-fc)5-(fl.(f-)-6))|]  = 

S[\{{nc+bd)±{bd)r\]={{a,b,c,dUac.bdr,{hdn 

5.  Equivalence  of  USTOCS  Machines  and  UCRE’s 

\N’e  will  show  in  this  section  that  USTOCS  machines  and  UCRE's  are 
equivalent  in  power. 

5.1.  Construction  of  a  USTOCS  machine  from  a  UCRE 

We  will  show  (hat  a  regular  expression  with  y-'  can  be  converted  to  a 
finite  state  machines  with  r's.  It  is  easy  to  extend  this  construction  for  a  more 
general  case  of  UCRE. 

We  first  show  that  the  maximal  and  minimum  acceptance  set  of  a  URE 
are  regular  sets.  The  maximal  acceptance  set  of  a  URE  is  obviously  a  regular 
set.  The  following  Lemma  shows  that  it  is  also  true  for  the  minimum  accep¬ 
tance  set. 
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Lemma  6.1:  Minimum  acceptance  set  of  a  URE  is  a  regular  set. 

Proof;  We  use  induction  on  the  structure  of  URE.  Except  0,  all  operators 
treat  the  maximum  acceptance  set  and  the  minimum  acceptance  set  in  an 
identical  manner.  For  0,  we  take  the  intersection  of  two  sets.  As  regular  sets 
are  closed  under  intersection,  this  would  result  in  another  regular  set. 

To  convert  a  I’RE  to  a  ITSNf,  we  write  it  as  REI0RE2.  where  REl 
represents  the  maximal  acceptance  set  and  RE2  is  the  minimum  acceptance 
set.  For  each  one  of  them  a  state  machine  can  be  constructed.  The  total  com¬ 
posite  machine  can  be  written  as  follows.  Construct  a  new  start  state.  Connect 
7  arcs  to  I  and  F.  The  maximal  set  of  this  machine  is  the  same  as  the  max¬ 
imum  set  of  I'RE  because  the  machine  can  always  take  transition  to  the  first 
finite  state  machine.  Similarly,  the  minimum  acceptance  set  is  the  same  as 
that  of  URE  because  no  matter  which  r  the  machine  takes,  the  string  in 
minimum  set  belong  to  both  I  and  F. 

For  example,  consider  the  F’RE  {aaab*'^±a*bbb)aba .  The  maximal  set  of 
this  URE  can  be  written  as  {aaab*-\-a*bbb]aba  while  the  minimum  set  can  be 
written  as  (aaabbb)aba .  Therefore  the  UFSM  corresponding  to  the  URE  is  as 
shown  in  the  Figure  6.6. 

The  above  construction  can  lead  to  a  large  UFSM.  In  the  above  construc¬ 
tion  of  machine  for  the  minimum  acceptance  set,  we  may  have  to  take  the 
intersection  of  two  finite  state  machines  to  simulate  Q  operator.  This  may 
result  in  a  UFM  that  are  considerably  bigger  than  the  given  URE.  We  now 
provide  a  construction  that  keeps  the  size  of  UFSM  upto  a  constant  factor  in 


113 


URE  =  (aaab*^a*bbb)aba. 


F'igure  6.6.  URE  =>  UFSM 

size  of  URE. 

Theorem  6.2;  There  exists  a  linear  algorithm  to  convert  a  LT?E  info  a 
UFSM. 

Proof;  For  each  primitive  regular  expression  such  as  a  and  c,  we  construct  a 
FSM  as  shown  in  Figure  6.7.  The  controllable  choice  operator  is  implemented 
by  creating  a  new  initial  state  and  adding  f  arcs  from  the  new  initial  state  to 
initial  states  of  operand  machines.  The  uncontrollable  choice  operator  is 


Figure  6.7;  I’RE  =>  ITSM.  A  better  transformation 
implemented  by  creating  a  new  initial  state  and  adding  r  arcs  from  the  new 
initial  state  to  initial  states  of  operand  machines.  Concatenation  of  A  and  B  is 
implemented  by  means  of  <  arcs  from  the  6nal  states  of  I2  to  the  initial  state 
of  II,  Kleene-closure  is  implemented  by  adding  f  arcs  from  all  final  states  to 
the  initial  state  and  making  the  initial  state  final.  Q.E.D.  Figure  6.8  shows 
the  application  of  this  algorithm. 
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Figure  6.8;  Result  of  more  direct  transformation 
5.2.  Construction  of  UCRE’s  from  USTOC.S  Machines 

We  will  show  that  a  URE  can  be  constructed  from  a  UFSM.  It  is  easy  to 
extend  the  construction  to  USTOCS  machines.  We  first  show  that  a  UFSM 
can  be  written  as  a  conjunction  of  two  finite  state  machines,  one  for  maximal 
acceptance  set  and  one  for  minimum  acceptance  set.  Since  a  FSM  can  be  con¬ 
verted  to  a  RE,  the  URE  equivalent  to  a  UFSM  is  just  the  0  of  RE's  for  max¬ 
imum  and  minimum  RE’s. 

Theorem  6.3;  Minimum  acceptance  set  of  a  UTSM  is  a  regular  set. 
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Proof:  VN’e  first  use  Theorem  6.1  to  use  tau-acceptance  set  of  the  UFS.\I 
instead  of  the  minimum  acceptance  set.  We  show  the  result  by  reducing  the 
number  of  nodes  with  r-arcs.  Choose  any  node  with  n  out-going  t  arcs.  We 
replace  this  UFSNf  by  the  intersection  of  n  machines  in  which  this  node  will 
have  only  one  out-going  arc.  Since  such  a  node  can  be  combined  with  its  des¬ 
tination  node,  the  total  number  of  r  nodes  is  reduced  by  one.  Q.E.D. 

An  application  of  Theorem  6.3  is  shown  in  Figure  6.9. 


Figure  6.9:  Construction  of  regular  set  for  minL 

6.  Conclusions 

This  chapter  shows  how  hidden  actions  can  easily  be  incorporated  in  our 
theory  of  concurrent  processes.  We  provide  a  unified  treatment  of  demonic 
and  oracular  non-determinism.  We  believe  that  our  approach  leads  to  compart 
specification  via  i  and  more  general  semantics  via  r.  We  have  shown  in  this 
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(a+6+f+d)$'T 

Figure  6.10:  UFSNi  =>  URE 

chapter  that  the  STOCS  machines  with  uncontrollable  events  are  equivalent 
to  I’CRE  with  non-deterministic  or  (v5^). 
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CHAPTER  7 


Analysis  of  STOCS  Machines 


1.  Introduction 

Research  efforts  in  reasoning  about  programs  can  be  divided  into  two 
groups  -  manual  and  automatic.  Most  researchers  in  distributed  algorithms 
use  manual  reasoning  based  on  the  behavior  of  the  program.  Many  proof  sys¬ 
tems  have  been  developed  for  reasoning  about  safety  and  liveness  properties 
[.Apt  80.  Hoare  85,  Milner  80,  Misra  81,  Lamport  84].  Manual  analysis  is  error 
prone  and  cumbersome;  therefore,  we  will  restrict  our  discussion  to  automatic 
analysis  of  distributed  programs. 

Automatic  analysis  of  a  concurrent  system  consists  of  computer  explora¬ 
tion  of  all  its  possible  behaviors.  Many  concurrent  systems  are  based  on  finite 
state  machines,  making  them  particularly  amenable  to  computer  analysis. 
This  approach  has  been  used  by  many  researchers,  especially  for  the 
verification  of  communication  protocols  [Gerhart  80,  Aggarwal  84,  Blumer  86). 
There  are  two  main  hurdles  to  this  approach  -  the  number  of  processes  may 
not  be  known  initially,  and  the  number  of  states  may  be  too  large  for  explora¬ 
tion.  For  an  illustration  of  difficulties  involved  in  this  approach  consider  the 
mutual  exclusion  algorithm  in  a  ring  network  [Dijkstra  85,  Clarke  86).  If  we 
know  the  number  of  processes  initially  (say  5),  then  we  could  construct  the 
global  state  graph  and  check  for  any  property  in  the  graph.  However,  this 
approach  becomes  infeasible  if  the  number  of  processes  is  not  known  initially 
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or  is  large  (say  100). 

There  have  been  many  efforts  to  contaiD  the  state  explosion  problem. 
Many  researchers  [Dong  83,  Kurshan  85]  have  studied  this  problem  in  the  con¬ 
text  of  automatic  protocol  verification,  where  this  problem  is  dealt  with  by  col¬ 
lapsing  multiple  states  into  a  single  state  while  preserving  properties  that  are 
important  for  verification.  These  properties,  however,  are  limited  to  logical 
properties  such  as  liveness  and  safety,  whereas  we  also  include  functional  pro¬ 
perties.  Also,  their  effort  cannot  be  used  for  reasoning  in  networks  with  an 
unknown  number  of  identical  processes.  Clarke  et.  al.  [Clarke  86]  propose 
inductive  techniques  to  prove  properties  of  networks  with  identical  finite  state 
processes.  Their  approach  consists  of  establishing  a  correspondence  relation¬ 
ship  between  the  global  graph  of  n  processes  and  the  global  graph  of  n-l-1 
processes.  They  show  that  if  the  correspondence  can  be  established,  then  any 
formula  expressed  in  Indexed  Computation  Tree  Logic  (ICTL)  t  ''hich  holds  in 
the  initial  state  of  a  network  with  a  small  number  of  processes  will  hold  for  the 
network  with  a  large  number  of  processes.  However,  the  step  of  establishing 
the  correspondence  is  manual  and  could  be  difficult  enough  to  defeat  the  origi¬ 
nal  purpose  of  avoiding  manual  analysis.  Our  aim  in  this  research  is  to  minim¬ 
ize  human  involvement  during  the  analysis. 

In  this  chapter,  we  present  algorithmic  techniques  based  on  reachability 
for  the  analysis  of  distributed  systems.  Since  reachability  algorithms  face  state 
space  explosion,  we  have  used  two  methods  to  cut  down  the  state  space; 

!  a  proper  subset  of  branch  time  temporal  logic 
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exploitation  of  modularity  and  exploitation  of  symmetry.  Exploitation  of 
modularity  deals  with  techniques  which  analyze  a  system  in  a  modular 
manner.  Exploitation  of  symmetry  deals  with  symbolic  and  induction  tech¬ 
niques  which  avoid  the  global  state  space  exploration. 

This  chapter  is  organized  as  follows.  Section  2  discusses  exploitation  of 
modularity  in  analyzing  distributed  systems.  Section  3  discusses  exploitation  of 
symmetry  for  analysis  of  systems  expressed  in  the  STOCS  model.  Section  4 
makes  concluding  observations. 

2.  Exploitation  of  Modularity 

We  exploit  modularity  by  means  of  the  projection  analysis  method.  This 
method  studies  appropriate  parts  of  the  system  to  make  assertions  about  the 
global  behavior.  Projection  techniques  can  be  useful  for  analyzing  the  safety 
properties  of  concurrent  systems.  They  cut  down  the  global  state  space  by 
exploring  only  the  relevant  parts  of  the  specification.  It  is  for  the  user  to 
decide  which  parts  of  the  specifications  are  relevant. 

Exploitation  of  modularity  is  easier  in  the  STOCS  model  than  in  Petri 
nets  which  are  often  analyzed  for  the  reachable  configurations.  The  ease  of 
analysis  comes  from  the  following  reasons.  First,  the  easier  specification  of  par¬ 
tial  system  in  the  STOCS  model  leads  to  techniques  for  analysis  of  partial  sys¬ 
tems  and  their  use  for  assertions  about  the  global  behavior.  Second,  the 
STOCS  model  has  extra  information  about  which  place  belongs  to  which  pro¬ 
cess  (unit  assignment)  and  therefore  it  can  exploit  the  notion  of  a  process 
which  is  missing  in  Petri  nets.  Third,  all  the  unboundedness  of  the  STOCS 
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model  is  explicit  and  confined  to  *-states  which  makes  the  analysis  simpler. 

Safety  concerns  are  generally  phrased  as  "the  system  must  never  reach 
the  bad  state”.  Example  of  bad  states  are:  "two  processes  are  in  the  critical 
region”,  "there  is  no  token  in  the  token-ring”  and  "there  are  more  men  than 
women  in  the  ballroom”.  More  formally,  a  safety  property  of  a  STOCS 
machine  M  is  a  logical  statement  of  the  form:  Configuration  C  does  not  belong 
to  the  set  of  all  reachable  configurations.  Alternatively  it  could  be  based  on 
the  sequence  of  computation  and  may  assert  that:  the  string  of  computation  S 
does  not  belong  to  the  language  L  of  the  machine.  A  system  is  considered  safe 
if  it  satisfies  all  its  safety  properties.  Figure  7.1  shows  that  for  a  safety  pro¬ 
perty  it  may  be  sufficient  to  analyze  only  the  relevant  units.  This  reduces  not 
only  the  number  of  reachable  states,  but  also  the  complexity  of  analysis  if 
units  do  not  have  a  *-place.  These  units  corresponds  to  S-invariants  of  the 
Petri  net. 


(S-invarian  t) 


A  Petri  Net  A  STOCS  Machine 

Figure  7.1.  Modular  Analysis  of  STOCS  Machines 
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2.1.  Reachable  Configurations 


We  can  do  a  reachability  analysis  for  the  STOCS  model  with  the  advan¬ 
tage  of  exploring  just  a  suitable  projection  of  the  system.  The  analysis  of 
reachable  configurations  of  a  subset  of  a  system  is  based  on  the  observation 
that  if  a  process  cannot  reach  a  configuration  assuming  the  absence  of  some 
units  then  it  cannot  reach  that  configuration  in  their  presence.  Before  we 
state  our  theorem,  we  need  the  definition  of  projection.  The  projection  of  a 
configuration  over  a  set  S  is  defined  as  the  configuration  of  tokens  in  states 
belonging  to  S.  Let  R{M,C)  represent  the  set  of  all  configurations  of  a  STOCS 
machine  M  reachable  from  the  initial  configuration  C. 

Theorem  7.1:  Let  A/j  and  A/o  be  two  STOCS  machines.  Let  Cj  and  C2  be 
initial  configurations  of  both  STOCS  machines  respectively.  Then 

Proof:  From  definitions  of  projection,  execution  and  composition.  Q.E.D. 

This  theorem,  although  simple,  has  powerful  applications.  Using  the  theorem, 
it  suffices  to  prove  that  a  certain  configuration  is  not  reachable  in  a  partial 
system  to  prove  that  it  is  not  reachable  in  the  total  system.  We  next  show  that 
the  reachability  question  may  be  considerably  simpler  to  answer  for  a  partial 
system.  Theorem  7.2  gives  a  simple  algorithm  using  max-flow  techniques  to 
answer  any  reachability  question  on  a  STOCS  machine  consisting  of  a  single 
unit. 

Theorem  7.2:  Let  a  STOCS  machine  consist  of  a  single  unit  with  n  states, 
'i'here  exists  an  algorithm  which  given  any  initial  and  final  configuration 
answers  the  reachability  question  in  0(n®)  time  (independent  of  the 
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Places  that  lose  tokens  Places  that  gain  tokens 


€).=  Number  of  tokens  lost  by  itb  place 
c'i=  Number  of  tokens  gained  by  ith  place 
di  j=  OC  if  a  path  exists  otherwise  0 

Figure  7.2;  Construction  of  the  Max-flow  Graph 
configurations  themselves). 

Proof 

From  Lemma  4.2  any  unit  with  multiple  *-places  can  be  converted  to  a 
unit  U  with  a  single  *-place  by  merging  all  the  *-places.  We  construct  a  max- 
flow  graph  with  n-l-2  nodes(Figure  7.2).  We  have  one  node  for  each  place  in 
the  STOCS  machine.  We  divide  up  the  places  into  two  sets  -  places  which  gain 
tokens  (G)  and  places  which  lose  tokens  (L).  If  the  overall  final  configuration 
has  more  tokens  than  the  initial  configuration,  we  add  the  ‘-place  to  L,  other¬ 
wise  we  add  the  ‘-place  to  G.  We  connect  each  of  the  places  in  L  to  a  pseudo 
source  with  an  arc  of  capacity  equal  to  the  number  of  tokens  they  lose.  Simi¬ 
larly,  we  connect  each  of  the  places  in  G  to  a  pseudo  sink  with  an  arc  of  capa¬ 
city  equal  to  the  number  of  tokens  they  gain. 

We  also  connect  two  nodes  with  an  arc  of  infinite  capacity  if  there  is  a 
path  between  the  corresponding  places  in  the  STOCS  machine.  We  next  show 
that  the  final  configuration  is  reachable  if  and  only  if  the  maxflow  in  the  graph 
is  equal  to  the  maximum  of  the  number  of  tokens  in  the  initial  and  the  final 
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configuration. 


If  there  exists  a  maxflow  with  the  desired  value  then  all  the  edges  with 
the  finite  capacity  must  get  saturated.  This  implies  that  there  exists  a  way 
such  that  (1)  Places  connected  to  the  source  lose  desired  number  of  tokens  (2) 
Places  connected  to  the  sink  gain  desired  number  of  tokens  (3)  The  movement 
of  tokens  respect  the  reachability  in  the  graph.  These  three  facts  together 
imply  that  the  final  configuration  is  reachable. 

To  see  the  converse  assume  that  the  final  configuration  is  reachable. 
Reachability  must  respect  the  reachability  conditions  in  the  graph  and  there¬ 
fore  the  change  in  configuration  can  be  simulated  in  the  graph.  This  will 
make  the  graph  saturated  implying  the  desired  condition.  Q.E.D. 

For  example,  consider  the  buffer  process  with  size  n  in  the  producer  con¬ 
sumer  problem.  The  number  of  tokens  in  the  place  pj  represents  the  number 
of  empty  buffers  and  the  number  of  tokens  in  the  place  p^  represents  the 
number  of  filled  buffers.  Since  the  number  of  tokens  in  a  *-place  free  unit  is 
constant,  we  conclude  that  the  number  of  filled  buffers  can  never  exceed  n. 

The  previous  result  gives  us  an  efficient  algorithm  to  answer  any  reacha¬ 
bility  question  for  a  single  unit.  These  units  are  even  allowed  to  have  ‘-places. 
The  simplicity  in  analysis  comes  from  the  fact  that  the  tokens  within  a  single 
unit  are  not  constrained  and  can  move  freely.  The  problem  is  more  difficult 
with  the  presence  of  additional  units.  In  this  section  we  show  that  it  is  NP- 
complete  to  analyze  the  a  STOCS  machine  with  multiple  units  for  reachabil¬ 
ity.  We  impose  these  additional  restrictions  to  the  structure  of  STOCS 


125 


machine. 


(1)  There  are  no  *-place. 

(2)  Each  of  the  unit  is  acyclic. 

Theorem  7.3:  [Kanellakis  85]  The  following  problem  is  NP-complete. 
Instance:  A  STOCS  machine  S=(Ul,U2),  such  that  no  unit  has  *>place. 
Question:  Is  configuration  C  reachable? 

Proof:  This  proof  is  adapted  form  (Kanellakis  85). 

Jt  is  in  NP. 

This  is  proved  by  providing  the  steps  which  lead  to  the  configuration.  Since 
the  machine  is  acyclic,  the  number  of  steps  are  polynomial  in  its  size. 

Reduction  from  3-SAT. 

Instance:  A  set  U  of  variables,  collection  C  of  clauses  over  U. 

Question:  Is  there  a  satisfying  truth  assignment? 

For  each  variable,  we  make  a  process  as  shown  in  the  Figure  7.3  and  for  the 
collection  of  clauses  we  make  another  unit  as  shown  in  Figure  7.3.  The  initial 
configuration  is  shown  in  the  Figure.  The  boolean  formula  is  satisfiable  if  and 
only  if  the  STOCS  machine  can  reach  a  configuration  in  which  all  tokens  are 
in  the  last  state  of  their  units.  Each  component  in  the  unit  t/j,  decides  the 
value  of  a  variable.  Q.E.D. 

The  above  result  indicates  that  in  general  one  may  have  to  take  the  cross 
product  of  all  the  structures  traced  by  tokens. 
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Figure  7.3:  Reduction  of  3-SAT  to  reachability  in  acyclic  bounded  STOCS  machine 

2.2.  Language  of  the  STOCS  Machine 

So  far,  we  have  been  interested  in  reachable  configurations.  Other 
interesting  questions  can  be  posed  in  terms  of  the  language  of  a  given  machine. 

The  analysis  of  the  language  of  a  STOCS  machine  is  based  on  a  crucial  obser¬ 
vation  -  if  a  process  cannot  make  a  transition  assuming  the  absence  of  some 
units  then  it  cannot  do  so  in  their  presence.  This  observation  is  formalized  in 
Theorem  7.4  which  states  that  the  language  of  composition  of  two  STOCS 
machines  restricted  to  the  alphabet  of  both  STOCS  machines  is  a  subset  of  the 
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intersection  of  their  languages.  Mere  fonnally, 

Theorem  7.4:  Let  A/j,  and  M2  be  t^^o  STOCS  machines  with  //j  and  //o  as 
their  handshake  sets.  Let  H=H^r\H2  Then 
L(A/.,[)A/o)///  C  UMi}JHnL{M2)IH 

Proof;  From  the  definitions  of  composition,  execution  and  r€strictioD.Q.£‘.Z>.. 

For  example,  consider  the  producer  consumer  problem  with  an  infinite 
buffer  (Figure  3.2).  The  language  of  the  buffer  process  is  the  set  of  strings  con¬ 
sisting  of  symbols  put_iiem  and  get, Hem  such  that  the  number  of  put, item  is 
greater  than  or  equal  to  the  number  of  get, item.  Once  we  know  the  language 
of  the  buffer,  we  conclude  by  Theorem  7.4  that  no  matter  what  other  com¬ 
ponents  exist  in  the  system,  this  specification  must  hold.  For  the  mutual  exclu¬ 
sion  problem  (Figure  3.1),  the  language  of  the  synchronizer  process  is 
<reqrel>*.  With  this  we  are  guaranteed  that  no  matter  what  other  processes 
do,  there  cannot  be  two  consecutive  reqs.  Similarly,  the  chocolate  vending 
machine  owner  in  the  vending  machine  example  can  satisfy  himself  that  no 
customer  can  cheat  him  by  analyzing  the  language  of  the  vending  machine. 
The  language  of  the  vending  machine  consists  of  all  those  strings  such  that  the 
number  of  coins  is  greater  than  or  equal  to  the  number  of  chocolates  delivered. 
Note  that  it  would  be  harder  to  prove  such  things  for  Petri  nets. 

3.  Exploitation  of  Symmetry 

Exploitation  of  symmetry  is  facilitated  by  the  structure  of  the  STOCS 
model  because  tokens  make  it  easier  to  model  systems  with  many  identical 
processes.  As  most  distributed  systems  have  one  or  more  identical  sets  of 
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processes,  these  techniques  have  wide  applicability,  especially  to  the  networks 
with  the  sfar,  broadcast  or  the  ring  topolog)'  (see  Figure  7.4). 


client 


■tar-topology  broadcast-topology  ring-topology 

Figure  7.4:  \"irtual  Topologj-  for  Communication 


A  star  topology  consists  of  a  server  (master)  process  and  a  set  of  identical 
client  (slave)  processes.  Client  processes  interact  only  with  the  server  process 
forming  a  star  topolog}’.  This  topolog}'  is  common  in  centralized  systems  and 
various  network  servers  such  as  name  server  and  printer  server.  A  broadcast 
topology  consists  of  a  set  of  identical  processes  connected  to  a  broadcast 
medium  such  as  an  ethernet.  We  assume  that  messages  are  always  broadcast 
and  must  be  received  by  all  the  processes.  An  example  of  such  a  system  is  a 
set  of  identical  readers  and  writers  connected  to  a  ethernet.  A  ring  topology 
consists  of  a  set  of  identical  processes  communicating  in  a  circular  fashion. 
Each  process  has  two  neighbors  and  all  messages  originating  at  the  process 
must  go  through  one  of  the  neighbors.  This  topolog)’  of  processes  is  common 
for  local  area  networks  with  token  ring  such  as  the  Cambridge  Ring  Network 
[Needham  82]. 

All  of  the  above  networks  show  symmetry  and  it  is  desirable  to  have 
methods  to  reduce  the  global  state  space  by  exploiting  this  symmetry.  We  pro¬ 
pose  symbolic  and  induction  methods  in  this  chapter  (see  Figure  7.5). 
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Figure  7.5:  Analysis  of  Various  Topologies 

3.1.  Star  Topology 

The  symbolic  analysis  method  expresses  the  global  stale  in  terms  of  sym¬ 
bols  instead  of  computing  the  actual  global  state.  These  symbols  are  then 
manipulated  to  compute  other  reachable  global  states.  A  symbol  could  stand 
for  any  unspecified  component  of  the  system,  such  as  the  number  of  processes. 
With  this  method,  one  symbolic  state  represents  multiple  computed  states, 
thus  reducing  the  state  space  substantially. 

One  of  the  advantages  of  the  notion  of  toketi  in  STOCS  is  that  it  can 
represent  a  process;  therefore,  multiple  identical  processes  are  represented  by 
multiple  tokens  in  some  state.  If  the  number  of  processes  is  large  or  is  unk¬ 
nown  initially,  we  may  use  a  symbol  (say  »i)  in  a  state  to  represent  the  unk¬ 
nown  number  of  processes.  Now  we  do  the  rest  of  the  analysis  in  terms  of 
these  symbols.  We  use  symbolic  analysis  for  networks  with  either  a  star  or  a 
broadcast  topoIog>'.  A  star  topolog}'  is  shown  in  Figure  7.4.  A  STOCS 
representation  of  such  a  network  would  generally  have  two  units  -  one  for  the 
master  process  and  one  for  multiple  slaves.  The  multiplicity  of  slaves  is 
represented  by  presence  of  multiple  tokens  in  some  state.  We  will  use  two 
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methods  to  analyze  STOCS  with  star  topology  -  symbolic  reachability  and 
matrix  equations. 

Symbolic  Reachability 


Symbolic  reachability  of  a  STOCS  machine  is  done  by  constructing  the 
reachability  graph  of  its  configurations.  A  reachability  graph  is  a  directed 
graph  with  each  node  representing  a  marking  and  a  directed  edge  from  one 
marking  (say  Cj)  to  another  (say  C^)  if  there  is  a  handshake  that  takes  the 
STOCS  machine  from  marking  C|  to  C’2-  We  allow  coordinates  of  a  marking 
to  be  symbolic.  As  an  example  of  symbolic  analysis  consider  the  2-out-of-3 
problem. 


(n.0.0, 0,3,0) 

(n-1,  1,  0,  0,  2,  +Hn-1,  0.  1,  0,  0.  0,  1,  2,  1) 

(n-2,  2,  0.  0,  l,_2U(n-2!  1.  1  ,'P,4).JCJir2,  1,  0.  1,  1,  2) 


(n-3,  3.  0,  0,  0,  3) 
Dfadlock  ! 


(n-i,  0,  1,  1,0,  3) 


Figure  7.6:  Example  of  symbolic  analysis  of  STOCS 

The  2-out-of-3  problem  is  a  good  abstraction  of  many  resource  contention 
problems.  Assume  that  a  memory  scheduler  has  three  memory  blocks  and  that 
any  process  requires  two  memory  blocks  to  execute.  A  non-preemptive  pro¬ 
cedure  for  such  a  system  with  n  processes  is  given  in  Figure  7.6.  We  place  n 
tokens  in  the  state  s,  to  signify  n  processes  and  three  tokens  in  the  state  to 
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signify  availability  of  three  memory  blocks.  To  analyze  the  solution,  we  draw 
a  reachability  graph  of  its  configurations.  The  initial  configuration  is 
(n, 0,0, 0.3.0).  With  this  configuration  only  a  mem  handshake  can  take  place, 
resulting  in  the  configuration  (n-1, 1,0, 0,2,1)  which  is  explored  next.  This  pro¬ 
cedure  is  continued  until  all  nodes  in  the  graph  have  been  explored.  Following 
it  in  our  example,  we  find  that  a  deadlock  exists  if  the  number  of  processes  is 
greater  than  or  equal  to  3  (see  Figure  7.6). 

With  the  brute  force  method  of  taking  the  cross  product  of  all  possible 
states  of  all  processes,  there  would  be  4"^  states  for  a  system  with  25  processes, 
in  contrast  to  9  states  that  need  to  be  explored  if  the  symmetry  is  exploited. 
The  chief  disadvantage  of  this  method  is  that  the  reachability  graph  may  not 
be  finite,  u^notation,  first  introduced  by  (Karp  68],  can  be  used  to  make  the 
graph  finite  but  due  to  the  loss  of  information  it  can  only  solve  the  coverabil- 
ity  problemjPeterson  81).  As  this  method  is  independent  of  the  issues  that 
arise  due  to  the  symbolic  nature  of  coordinates,  we  do  not  discuss  this  method 
here  and  refer  interested  readers  to  [Peterson  81). 

Matrix  Equations 

Symbolic  reachability  can  sometimes  run  into  problems  when  the  reacha¬ 
bility  graph  is  dependent  on  the  value  of  symbols.  Matrix  equations,  another 
approach  to  analyzing  STOCS,  are  as  easy  to  analyze  with  symbols  as  without 
them.  We  will  use  a  variation  of  the  example  of  a  memory  server  to  illustrate 
the  analysis  with  matrix  equations.  We  will  assume  that  the  memory  server 
has  m  blocks  (instead  of  3)  and  that  it  uses  a  preemptive  algorithm  to  grant 
requests  (see  Figure  7.7).  Our  task  is  to  check  whether  deadlock  is  possible  in 


132 


such  a  system.  Various  steps  in  using  matrix  equations  are  as  follows: 


Figure  7.7:  Preemptive  Memory  Server 

(1)  Let  the  initial  configuration  of  STOCS  for  the  problem  be  A/,-  which  is 
(?)  ,0,0.0, r7J  ,0)  for  our  example.  We  are  interested  in  knowing  if  there  is  a 
possibility  of  deadlock.  It  is  easy  to  check  that  the  only  possible  deadlock 
states  are:  (n,0,0,0.0,m)  and  (0.0,y,n*y,m,0).  Thus  the  question  of 
deadlock  reduces  to  the  question  of  reachability  of  any  of  the  above  states 
for  some  value  of  n.  m  and  y. 

(2)  We  assign  a  variable  A',  for  each  possible  occurrence  of  a  handshake.  This 
variable  represents  the  number  of  times  that  particular  handshake  must 
occur  to  reach  the  final  configuration.  For  example,  A",  represents  the 
number  of  times  transition  wcm  occurs  from  state  Sj  and  A'o,  the  number 
of  times  from  state  So  Similarly,  rel  occurs  A'3  times  from  state  So.  A'4 
times  from  state  S3,  and  A'S  times  from  state  S4.  Due  to  the  synchronous 
nature  of  execution,  we  conclude  that  the  transition  tiiem  from  state 
must  have  occurred  A’'j+A'2  times  and  transition  rel,  X^+X^+Xb  times. 

(3)  Each  of  the  above  handshakes  has  an  additive  effect  on  the  configuration. 
For  example,  the  handshake  mem  from  state  s,  has  the  effect  of  removing 
one  token  from  state  S|  and  adding  one  to  So  (represented  as  (- 
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1,1, 0,0, 0,0)).  If  the  final  state  is  reachable  then  the  cumulative  effect  of 
all  handshakes  can  be  written  as: 


A/^=A/.+A',(-l,+  l,0,0,0,0) 
+.V2(0,-1,+  1, 0,0,0) 
+A'3(+1,-1,0.0,0,0) 
+A*4{0,0,-1,+ 1,0,0) 

+A'5(+ 1,0, 0,-1, 0,0) 
+(A’,+A'o)(0.0,0,0,-1,+  1) 
+(A3+A4-I-A  5)(0,0,0,0,4-1,— 1) 


This  can  also  be  written  as  AM=AX  where  AJV/=A/y— A/,,  A  is  the 
appropriate  matrix  calculated  from  above  and  A’'=(A’'2,A’'2,A'3.A’'4,A’'5). 


For  our  example.  A  is  as  follows:  A 


-1 

0 

1 

0 

1 

1 

-1 

-1 

0 

0 

0 

1 

0 

-1 

0 

0 

0 

0 

1 

-1 

-1 

-1 

1 

1 

1 

1 

1 

-1 

-1 

-1 

Note  that  A  is  independent  of  symbols  used  and  therefore  can  be  calcu¬ 
lated  just  from  the  structure  of  the  STOCS  machine. 


(4)  We  next  check  whether  the  above  system  of  equations  has  a  non-negative 
integral  solution.  For  our  example,  we  find  that  a  solution  is  not  possible 
unless  n=0.  Now  it  is  easy  to  show  that  if  the  system  of  equations  does 
not  have  a  non-negative  integral  solution  then  the  final  configuration  Mj^ 
is  not  reachable.  Hence,  we  deduce  that  the  configurations  (n,0,0,0,0.m) 
or  (0,0,y,n-y,m,0)  are  not  reachable  and  therefore  the  system  is  free  from 
deadlock. 
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The  chief  disadvantage  of  this  method  is  that  even  though  a  non-negative 
integral  solution  to  above  equations  may  exist,  the  final  configuration  may  not 
be  reachable.  This  problem  is  the  same  as  the  one  faced  during  the  analysis  of 
Petri,  nets  using  Matrix  EquationsfMurata  84]. 

3.2.  Broadcast  Topology 

This  topolog>'  assumes  a  synchronous  broadcast  primitive  which  is  an 
extension  of  one-to-one  synchronous  i/o  of  CSP.  The  usefulness  of  such  mul¬ 
tiprocess  synchronization  constructs  is  discussed  in  [Ramesh  86).  A  synchro¬ 
nous  broadcast  requires  that  a  message  be  sent  only  if  all  other  processes  are 
ready  to  receive  it.  We  will  use  the  example  of  readers  writers  problem  [Cour- 
tois  71]  to  show  that  symbolic  reachability  can  be  useful  for  algorithms  that 
use  broadcast  topolog>'. 

The  readers  writers  problem  is  as  follows.  Assume  that  a  database  is  being 
updated  by  certain  processes  called  writers  and  consulted  by  some  other 
processes  called  readers.  To  avoid  any  concurrency  conflict,  these  processes 
can  access  the  database  only  with  the  following  constraints: 

(1)  At  most  one  writer  can  access  the  database,  (w-w  conflict) 

(2)  A  reader  and  a  writer  cannot  access  the  database  at  the  same  time,  (r-w 
conflict) 

(3)  Multiple  readers  are  allowed  to  access  the  database  at  the  same  time,  (r-r 
okay) 

(4)  To  avoid  the  possibility  of  starvation  of  a  writer,  we  add  the  constraint 
that  a  reader  cannot  enter  the  critical  region  if  a  writer  is  waiting  to 
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enter  it. 


For  the  analysis  of  broadcast  topology',  we  w'ill  constrain  a  unit  of  a 
STOCS  machine  to  have  at  most  one  token.  For  the  readers/writers  problem 
each  process  forms  a  separate  unit  as  it  interacts  with  every  other  process.  The 
STOCS  machine  for  a  single  reader  and  a  single  writer  is  shown  in  Figure  7.8. 
T  events  used  in  the  Figure  7.8,  are  internal  to  the  process  and  do  not  need  any 
interaction  with  the  external  world.  A  minus  sign  before  a  symbol  (e.g.  -enter) 
indicates  that  it  is  a  broadcast  and  can  take  place  only  if  other  processes  can 
take  the  corresponding  plus  transition  {-henter).  We  define  the  status  of  a  net¬ 
work  of  processes  as  a  tuple  with  the  number  of  processes  that  are  in  the 
statef  as  its  coordinate.  Thus,  (w,0,0)  means  that  xv  processes  are  in  state 
1,  and  there  are  no  processes  in  state  2  and  3.  The  status  reachability  of  the 
above  problem  is  shown  in  Figure  7.8.  The  analysis  shows  that  (1)  the  system 
does  not  have  any  deadlock  state  (2)  there  is  at  most  one  writer  in  state  s^  at 
any  time,  and  (3)  readers  and  writers  are  never  in  state  ^2  same  time. 

Note  that  the  reachability  graph  has  a  special  edge  for  letting  i  readers  read 
the  database  at  the  same  time.  Such  an  edge  is  added  if  a  configuration 
C'2=((jr,0),(r-1, 1.0.0))  is  reachable  from  some  configuration 
C'j=:((u’,0),(r, 0,0,0))  such  that  there  is  a  decrease  in  the  value  of  only  symbolic 
coordinates  of  Cj  (i.e.  r).  Such  an  edge  corresponds  to  t  instances  of  a  transi¬ 
tion. 


*  a  process  is  said  to  be  in  slate  t  if  its  token  is  in  state  t . 
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Figure  7.8:  Readers  Writers  Problem 

3.3.  Ring  Topology:  Induction  Analysis 

As  the  number  of  processes  in  a  network  (say,  n)  may  be  a  large,  variable 
or  unknown  quantity,  the  construction  of  the  global  state  graph  is  not  feasible. 
It  is  desirable  to  have  a  method  that  analyzes  the  network  with  a  small 
number  of  processes  and  then  generalizes  results  to  a  larger  n.  The  key  idea 
that  can  be  frequently  applied  for  many  systems  is  that  of  induction.  Instead 
of  studying  the  system  with  a  large  or  an  unknown  number  of  processes,  this 
method  analyzes  it  with  a  small  number  of  processes  and  then  the  invariance 
of  assertions  is  analyzed  with  the  increase  in  the  number  of  processes.  Since 
the  analysis  is  done  for  a  small  number  of  processes,  the  reduction  in  the  glo¬ 
bal  state  space  is  substantial.  The  principle  of  induction  states  that  if  an 
observer  cannot  distinguish  between  two  systems  with  i  and  t+l  processes 
connected  in  a  linear  fashion  even  with  an  infinite  input  to  both  systems,  then 
he  also  cannot  distinguish  between  a  system  with  i  processes  and  any  other 
system  with  more  than  i  processes.  It  follows  that  it  is  sufficient  to  analyze 
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the  network  with  i+l  processes  for  any  input-output  assertion  on  more  than  t 
processes.  This  principle  is  illustrated  in  Figure  7.8. 


Figure  7.8;  Induction  Principle  for  Ring  Topology 

We  illustrate  this  by  analyzing  the  dining  philosopher’s  problem,  of 
which,  Hoare  [Hoare  85]  remarks  that,  "There  is  no  hope  that  a  computer  will 
ever  be  able  to  explore  all  these  possibilities  (for  a  deadlock).  Proof  of  the 
absence  of  deadlock,  even  for  quite  simple  finite  processes,  will  remain  the 
responsibility  of  the  designer  of  concurrent  systems."  To  arrive  at  this  con¬ 
clusion,  he  computes  the  number  of  reachable  states  of  philosophers  by  taking 
the  product  of  their  states.  We  claim  that  with  a  smarter  way  of  enumerating 
possibilities,  a  computer  need  not  explore  all  of  them.  For  example,  we  could 
analyze  our  algorithm  for  two  dining  philosophers  instead  of  five  philosophers 
which  will  bring  the  number  of  possible  states  to  a  small  quantity.  We,  of 
course,  have  to  show  that  the  analysis  does  not  change  with  the  number.  We 
next  describe  the  problem,  a  deadlock  free  solution  and  its  automatic  analysis. 
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3.3.1.  Simple  Induction 

This  problem,  due  to  Dijkstra,  requires  an  algorithm  for  philosophers  who 
are  sitting  around  a  circular  table.  There  are  five  philosophers  and  five  forks, 
each  of  which  is  between  two  philosophers.  There  is  a  bowl  of  spaghetti  in  the 
center  which  can  be  eaten  by  any  philosopher  but  its  tangled  nature  requires 
that  a  philosopher  use  both  his  left  and  right  forks. 

A  solution  which  assumes  synchronous  communication  is  as  follows.  A 
philosopher,  when  hungry,  either  picks  up  both  the  forks  simultaneously  or 
waits  for  them  to  be  available.  This  way  of  picking  forks  guarantees  that 
there  will  not  be  any  deadlock.  To  e.xpress  our  solution,  we  assume  that 
philosopher  owns  fork  and  needs  to  ask  only  the  right  neighbor  for  the  use 
of  >  +  fork.  For  convenience  we  will  use  ti- ^  to  denote  that  i. picks  up  fork.j 
and  </,  y  to  denote  that  i.puts  down  fork.j.  With  this  notation,  Figure  7.9 
shows  the  solution  expressed  in  the  STOCS  model. 


PHILO)  PHILO+1) 

Id-  ‘V-’H 


/ 

0 


't+l,i+2 


PHILO)  I  IPHILO+1)  Reachability  for  two  philosopher* 


Notation 

«,■  y  =  i. picks  up  fork.) 
(/,■  y  =  i.puts  down  fork.j 


Figure  7.9:  Dining  Philosophers:  Analysis 
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To  show  that  the  solution  is  deadlock  free,  we  could  use  a  computer  to 
explore  the  reachable  states.  In  the  past,  automatic  analysis  meant  exploring 
the  cross  product  of  all  possible  states  of  five  philosophers  and  five  forks  (or 
hundred  philosophers  and  hundred  forks  for  a  hundred  philosopher  problem). 
Our  technique,  in  contrast,  exploits  the  symmetry  in  the  problem  so  that  the 
complexity  of  analysis  for  five  philosophers  is  the  same  as  that  of,  say,  one 
hundred  philosophers.  Various  steps  in  our  technique  are  as  follows: 

(1)  Let  Sl'Si^=(PHILi\\..  \  I Find  the  smallest  value  of  k  for 

which  For  most  symmetric  cases  k=l  or  2  will  suffice. 

For  dining  philosophers,  S)’S^=S)'S2  as  shown  in  Figure  7.10. 

(2)  To  analyze  a  ring  with  any  number  of  units,  say  n,  it  is  sufficient  to 
analyze  it  with  k  +  l  units.  Thus,  for  our  case  it  is  sufficient  to  analyze  the 
system  with  two  philosophers  to  make  any  assertion  about  a  system  with 
five  or  one  hundred  philosophers. 

(3)  We  next  construct  a  reachability  graph  for  two  philosophers  and  find  that 
there  is  no  state  with  out-degree  equal  to  zero  (see  Figure  7.10).  We  con¬ 
clude  from  this  that  the  system  with  five  philosophers  will  also  be 
deadlock  free. 

3.3.2.  Induction  Analysis  with  Filters 

Observe  that  simple  induction  required  that  the  observer  not  be  able  to 
detect  the  difference  on  any  input.  This  constraint  may  prove  too  restrictive  to 
apply  induction  techniques  for  certain  problems.  Therefore,  we  relax  the  con¬ 
dition  using  the  concept  of  filters.  Filters  are  formal  mechanisms  to  capture 
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the  condition  that  not  all  inputs  may  be  possible  for  the  system  and  therefore 
y,e  are  willing  to  call  two  systems  equivalent  as  long  as  their  outputs  do  not 
differ  on  possible  inputs. 


ro 

h 


r:  request  mestagi 
t:  token  message 


w;  white n;  normal 
b:  black  d:  delayed 
c:  critical 


Figure  7.11:  Mutual  Exclusion  in  a  Ring 
We  illustrate  the  use  of  filters  by  a  mutual  exclusion  algorithm  in  a  ring  net¬ 
work.  Clarke  et.al. [Clarke  86]  use  the  same  example  to  illustrate  their  manual 
induction  technique.  Dijkstra[Dijkstra  86]  also  uses  the  same  example  to  show- 
how  regular  expressions  can  be  used  to  prove  the  correctness  of  certain  algo¬ 
rithms.  His  proof,  again,  is  manual.  The  mutual  exclusion  problem  in  a  ring  of 
processes  is  as  follows.  The  machines  are  connected  in  a  ring  fashion  and  can 
communicate  with  their  neighbors.  Each  process  can  be  in  one  of  the  three 
states:  normal  (n),  delayed  (d)  or  critical  (c).  A  process  can  execute  the  critical 
region  only  if  it  is  in  the  critical  state.  The  objective  is  to  ensure  that  at  any 
time  at  most  one  machine  is  in  the  critical  state.  We  introduce  the  notion  of  a 
token  which  is  held  by  a  single  machine.  To  avoid  passing  tokens 
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unnecessarily,  ^^e  introduce  a  request  signal  which  indicates  an  interest  in  the 
token.  A  process  that  wants  to  execute  the  critical  region  and  does  not  have 
the  token  gets  delayed.  Following  Dijkstra’s  algorithm,  tokens  are  sent  to  the 
left,  whereas  request  signals  are  sent  to  the  right  (see  Figure  7.11).  Wt  color 
each  of  the  process  as  white  or  black  depending  upon  whether  an  interest  in 
the  token  exists  to  the  left.  Figure  7.11  shows  the  example  of  a  distributed 
mutual  exclusion  algorithm  in  a  ring  network  expressed  in  the  STOCS  model. 

If  we  try  to  apply  the  induction  technique  that  was  used  for  dining  philo¬ 
sophers  we  find  that  step  1  is  not  applicable,  that  is,  there  does  not  exist  any  k 
for  which  S)'Sf.  is  the  same  as  5}'5/t+j.  This  can  also  be  seen  intuitively  from 
the  algorithm.  An  observer  can  detect  the  number  of  processes  he  is  con¬ 
nected  to  by  sending  multiple  token  messages.  The  number  of  processes  in  a 
system  would  be  equal  to  the  maximum  number  of  token  messages  that  are 
absorbed  by  the  system. 


{m 


Pi  lP,+i  I  Filter 

Figure  7.12:  Composition  of  two  processes  with  the  filter 
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To  solve  this  problem,  we  use  the  notion  of  Slters  to  constrain  the 
observer  to  send  at  most  one  more  token  message  than  he  receives  from  the 
output.  We  now  show  the  steps  in  the  modified  induction  technique  using  the 
mutual  ring  example. 

(1)  Model  all  the  constraints  on  the  input  output  behavior  through  a  process 
called  FILTER.  Figure  7.12  shows  such  a  filter  for  our  example. 

(2)  \’erify  that  a  process  in  the  system  indeed  satisfies  the  constraint  imposed 
by  the  filter.  If  we  substitute  all  request  messages  in  an  ENTITY  by  t, 
L-i  by  fj  arH  t.  by  (q  "e  do  get  the  filter  as  a  result. 

(3)  Find  the  smallest  k  such  that  a  filtered  system  with  k  units  is  identical  to 
a  filtered  system  with  k+l  units.  That  is, 

FILTbrS\.=(E^Tm\\\....  I  l£AT/r>;+t_,|lE/Lr£i?). 

For  our  example  we  find  (hat  FILTS)'?^y^F/LTS)'S2  but 
FJLTF)S.=F1LT.S)'S\.  It  is  easy  to  check  that  for  any 

value  of  k. 

(-4)  Thus  from  the  principle  of  induction  we  deduce  that  it  is  sufficient  to 
analyze  the  algorithm  with  three  processes  to  make  an  input-output  asser¬ 
tion  on  any  number  of  processes  greater  than  three. 

4.  Conclusions 

Due  to  decreasing  costs  of  hardware  and  advances  in  \XSI  technology, 
systems  with  multiple  processes  have  become  popular.  Typically,  a  concurrent 
algorithm  on  such  architectures  consists  of  multiple  processes  each  of  themi 
executing  a  very  simple  procedure.  Examples  of  such  paradigms  of 
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computation  are  Hypercube  algorithms  and  Connection  Machine  algorithms. 
There  is  an  acute  need  for  systems  that  can  analyze  such  distributed  systems. 
Automatic  analysis  of  even  finite  state  systems  runs  into  the  problem  of  state 
space  explosion.  Since  most  distributed  systems  show  symmetry,  we  suggest 
techniques  that  exploit  symmetry  to  reduce  the  state  space.  STOCS  is  a  useful 
model  to  represent  symmetric  distributed  systems.  We  use  symbolic  reachabil¬ 
ity  and  matrix  equations  to  analyze  systems  expressed  in  the  STOCS  model 
with  star  or  broadcast  topology.  We  use  induction  to  reduce  the  number  of 
process  that  need  to  be  analyzed  in  a  ring  network. 
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CHAPTER  8 


ConC:  Embedding  of  STOCS  in  C 

1.  Introduction 

The  availability  of  cheap  hardware  and  communication  facilities  has  made 
distributed  systems  an  attractive  proposition.  However,  the  difficulty  of  con¬ 
current  programming  has  kept  it  away  from  average  programmers  (Chandy 
85],  In  present  concurrent  programming  languages  systems,  the  communica¬ 
tion  aspects  of  a  program  are  interwoven  with  computational  aspects.  As  a 
result,  any  analysis  of  the  communication  structure  of  the  program  is  difficult. 
By  analysis,  we  mean  questions  such  as  -  "Is  a  certain  sequence  of  events  possi¬ 
ble?",  ’’Is  a  certain  state  reachable?”  etc.  To  make  concurrent  programming 
easier,  the  system  should  provide  automatic  analysis  of  the  communication 
aspects  of  a  program.  In  addition,  the  communication  aspects  of  the  software 
should  be  specified  at  a  very  high  level  of  abstraction.  Therefore,  we  had  two 
goals  in  designing  the  communication  primitives  -  high  level  specification  and 
onalyzability. 

In  this  chapter,  we  propose  two  new  constructs  for  concurrent  program¬ 
ming  -  handshake,  a  generalization  of  the  remote  procedure  call,  and  vnit,  a 
communication  structuring  mechanism.  A  handshake  is  shared  among  two  or 
more  processes.  Each  process  has  a  procedure-like  interface  with  a  handshake. 
When  all  the  participating  processes  call  their  handshake  procedures,  the 
shared  handshake  body  is  executed.  The  unit  construct  is  used  to  restrict  the 
sequence  of  possible  calls  to  various  handshake  procedures  and  thereby  provide 
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a  synchronization  mechanism  between  multiple  processes.  Thus,  a  unit  can  be 
viewed  as  an  automaton  that  specifies  all  possible  sequences  of  handshake  pro¬ 
cedures.  The  handshake  and  unit  constructs  form  part  of  the  STOCS  Model. 
Since  STOCS  machines  are  theoretically  equivalent  to  Petri  Nets,  all  the 
analysis  techniques  for  Petri  nets  such  as  coverability  tree  (Karp  68]  and 
matrix  equations  (Murata  84]  are  directly  applicable  to  the  STOCS. 

In  our  paradigm,  we  support  separation  of  concerns  by  separating  inter¬ 
nal  objects  and  ezternal  objects.  Internal  objects  are  specified  in  any  standard 
sequential  programming  language  such  as  Pascal,  C  or  sequential  Ada.  These 
objects  are  used  mainly  to  capture  the  computation  aspects  of  the  system  and 
do  not  concern  themselves  with  either  synchronization  or  communication. 
External  objects,  on  the  other  hand,  are  written  as  units  and  handshakes. 
They  specify  the  computation  that  is  directly  related  to  communication.  For 
example,  synchronization  is  handled  by  these  objects.  They  are  mechanically 
analyzable  for  most  interesting  properties  as  their  expressive  power  is  less  than 
that  of  Turing  machines, 

The  rest  of  the  chapter  is  organized  as  follows.  Section  2  discusses  the 
related  work  in  the  area  of  constructs  for  concurrent  programming.  In  section 
3.  we  discuss  our  constructs  for  concurrent  programming.  Section  4  discusses 
the  interaction  between  computation  and  communication  objects  in  our  para¬ 
digm.  Section  5  discusses  the  status  of  the  ConC  project. 

2.  Related  Work 

Andrews  and  Schneider  [Andrews  83]  classify  concurrent  languages  into 
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three  categories.  The  shared  memory  based  programming  languages  assume 
that  variables  can  be  accessed  by  any  process.  To  guarantee  mutual  exclusion, 
constructs  such  as  critical  regions  and  monitors  are  used.  Example  of  such 
languages  are  Concurrent  Pascal,  Mesa  [Mitchell  79]  and  Modula.  Message 
based  programming  languages  provide  send  and  receive  constructs  for  com¬ 
munication.  Examples  of  such  languages  are  CSP  [Hoare  85]  and  PLITS  [Feld¬ 
man  79].  Operation  based  languages  combine  aspects  of  the  other  two  classes. 
They  provide  remote  procedure  call  as  the  primary  means  of  process  interac¬ 
tion.  Ada,  Distributed  Processes  [Brinch  Hansen  78]  and  SR  [Andrews  82]  fall 
in  this  class.  Since  the  handshake  construct  extends  the  remote  procedure  call 
for  multi-party  interaction,  it  belongs  to  this  class  as  well.  The  features  that 
distinguishes  ConC  from  related  efforts  are  as  follows: 

(1)  Synchronous  Communication;  We  believe  that  programmers  of  distri¬ 
buted  systems  should  not  have  to  deal  with  asynchronous  communication  as  it 
makes  a  program  difficult  to  debug,  and  analyze.  In  this  respect,  we  differ  from 
FLITS,  and  agree  with  the  philosophy  of  programming  languages  such  as  Ada 
and  CSP. 

(2)  Multi-Process  Interaction:  Many  applications  require  interaction 
between  more  than  two  processes  and  the  user  can  program  at  a  high  level  if 
such  a  facility  is  directly  provided  by  the  language.  CIRCAL  [Milne  85],  Rad¬ 
dle  [Forman  86],  Multi-way  Rendezvous  [Charlesworth  88],  PPSA  [Ramesh  87], 
and  Script  [Francez  83]  have  also  suggested  multi-party  interaction  in  one 
form  or  another.  CIRCAL,  Raddle  and  PPSA  allow  synchronization  based  on 
matching  of  event  names  but  do  not  provide  a  remote  procedure  call-like- 


interface.  Script  shows  bow  details  of  multi-process  interaction  can  be  hidden 
but  does  not  provide  direct  support  for  the  multi-party  interaction.  None  of 
them  supports  any  form  of  analysis. 

(3)  Analysis  of  Interaction:  As  most  errors  in  concurrent  systems  arise  due 
to  erroneous  specification  of  process  interaction,  any  analysis  of  the  interaction 
will  greatly  increase  the  programmer’s  productivity.  None  of  the  above  men¬ 
tioned  languages  supports  analysis.  Such  analysis  is  more  common  for  com¬ 
munication  protocols  which  is  done  mainly  for  specifications  expressed  in  State 
Machines,  Petri  nets  or  bounded  variable  programming  languages  [Sunshine 
7S|.  One  of  the  early  attempts  to  incorporate  such  analysis  in  a  full  fledged 
programming  language  was  Path  Expressions  [Campbell  74]].  Path  Pascal 
[Campbell  79]  based  on  Path  expression  is,  however,  a  shared  memory  based 
language.  Path  expressions  are  also  cumbersome  to  write  and  understand  for 
even  slightly  complex  constraints.  In  addition,  the  analysis  provided  by  Path 
Pascal  is  not  as  extensive  as  that  provided  by  ConC. 

(4)  Communication  Abstraction  Mechanism;  Researchers  in  program¬ 
ming  languages  have  found  abstractions  a  useful  mechanism  to  increase  the 
understandability  of  the  software.  Consequently,  current  programming 
languages  provide  control  abstraction  through  loop  constructs  and  procedure 
calls,  and  data  abstraction  through  abstract  data  types.  One  of  the  main  func¬ 
tions  of  an  abstraction  is  to  provide  only  structured  access  to  the  primitives. 
For  example*  a  control  abstraction  mechanism  seeks  to  provide  a  structured 
use  of  goto’s.  Similarly,  the  complexity  of  concurrent  software  has  made  it 
necessary  that  goto’s  of  the  communication  world  (send,  receive,  remote 
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procedure  calls  e(c.)  be  allowed  only  in  a  structured  manner.  Path  expressions 
specify  the  sequence  of  procedures  that  can  be  made  on  shared  variables  and 
therefore  can  be  termed  as  the  first  attempt  for  providing  such  a  mechanism. 
Frahcez  and  Hailpern  [Francez  83]  were  the  first  to  coin  the  term  and  use  it  in 
their  proposal  of  Script.  ConC  provides  structuring  of  the  communication 
primitives  through  the  unit  construct. 

Table  1  summarizes  some  of  the  well  known  concepts  that  can  be  shown 
to  be  special  cases  of  constructs  provided  in  the  ConC. 


Feature 

Example 

ConC 

Synchronous  communication 

CSP 

handshake 

Remote  procedure  call 

Ada 

parametrized  handshake 

Multi-process  interaction 

Raddle 

multi-process  handshake 

Abstraction  Mechanism 

Script 

unit 

Path  Constraints 

Path  Pascal 

unit  expressions 

Reachability 

Petri  Nets 

STOCS 

Table  8.1:  Special  Cases  of  Handshake  and  Unit  Constructs 


3.  Constructs 


3.1.  Handshake  Construct 

The  remote  procedure  call  has  become  one  of  the  most  favored  communi¬ 
cation  primitive  because  of  its  similarity  to  the  local  procedure  call,  a  well 
understood  concept.  A  handshake  is  a  remote  procedure  call  generalized  for 
multiple  parties. 

A  handshake  consists  of  the  declaration  of  handshake  procedures  and  a 
shared  body.  The  body  of  the  handshake  is  executed  only  when  all  handshake 
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procedures  have  been  called  by  their  respective  processes.  Thus,  handshake 
can  be  used  as  a  synchronization  point  of  multiple  proceses.  For  illustration, 
consider  the  distributed  players  problem.  Assume  that  there  are  four  players 
\\l)o  are  interested  in  playing  various  games  as  shown  in  Figure  8.1.  Joe  is  wil¬ 
ling  to  play  chess,  bridge  or  poker.  Mary  is  willing  to  play  any  of  the  games 
while  Jack  and  Bob  play  only  bridge  or  poker.  Playing  a  game  requires  rendez¬ 
vous  between  two  or  more  processes.  This  is  achieved  by  handshake  construct 
as  shoAvn  in  Figure  8.2. 


Distributed  Players 


Joe 

o 

Chess:  Mary 
Bridge:  Jack  Mary  Bob 
Tennis:  Mary 


Jack 


Q 

Poker:  Mary  Bob 
Bridge:  Joe  Mary  Bob 


Bob 


O 


Mary 


O 


Poker:  Jack  Mary 

Bridge:  Joe  Jack 
Mary 


Chess:  Joe 
Poker:  Jack  Bob 
Bridge:  Joe  Jack  Bob 
Tennis:  Joe 


Figure  8.1:  Distributed  Player  Problem 

The  above  example  illustrated  the  use  of  the  handshake  construct  for  syn¬ 
chronization.  The  handshake  construct  is  also  useful  for  communicating  data 
from  one  process  to  the  other.  The  handshake  procedures  may  be  called  with 
parameters.  When  the  handshake  is  executed  by  the  master  of  the  handshake, 
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• 

• 

• 

bridgeO; 

• 

• 

bridgeO; 

• 

• 

bridgeO; 

• 

• 

process  Joe 

process  Jack 

process  Mary 

Figure  8.2;  Handshake  Construct  for  Distributed  Player  Problem 
all  the  parameters  are  considered  available.  The  body  of  the  handshake  can 
use  any  of  the  parameters  or  its  own  local  variable.  As  an  example  of  a 
handshake  with  parameters,  consider  the  same  example  of  distributed  players. 
Assume  that  Joe  decides  where  they  should  meet  for  the  game  of  bridge.  The 
revised  handshake  declaration  is  shown  in  Figure  8.3. 
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handshake  bridge; 

procedure  Joe.bridge(Joeplace:  alpha); 
procedure  Jack.bridge(var  Jackplace:  alpha); 
procedure  Mary.bridge(var  Maryplace:  alpha); 
procedure  Bob.bridge(var  Bobplace;  alpha); 

begin 

Jackplace  =  Joeplace; 

Maryplace  =  Joeplace; 

Bobplace  =  Joeplace; 

end; 


Figure  8.3:  Handshake  with  Parameters 

We  next  describe  the  syntax  for  the  handshake  construct  using  BNF.  We  use 
{}  to  denote  zero  or  more  repetitions  of  the  enclosed  expression.  Note  that 
the  syntax  of  a  handshake  is  symmetric  for  caller  and  callee  in  contrast  to 
Ada’s  rendezvous  where  the  callee  uses  accept  and  the  caller  uses  entry  pro¬ 
cedure  call  to  make  a  rendezvous. 


;  a  handshake  specification 

<handshake-d(l>  ;:=  handshake  id  <global-declaration> 
{<proc. specs>}  < local-declaration >  <body> 

;  this  section  specifies  types  used  in  declaring  parameters 
<global-decIaration>  ::=  the  usual  const  and  type  declarations 

;  headers  for  various  procedures  which  share  the  body 
<proc. specs >  procedure  id  (  {  <param>  }  ) 

<param>  ;:=  [war]  id  <type> 

<local-declara(ion>  local  variable  declaration 

;  the  body  is  executed  when  the  handshake  takes  place 
<body>  :=  the  usual  programming  language  body 

As  another  example  of  the  handshake  construct  consider  the  synchronous  send 
provided  in  the  Unix  as  a  library  facility.  The  handshake  description  of  such  a 
primitive  in  ConC  is  shown  in  Figure  8.4.  It  specifies  that  when  process  Pi 
calls  send  and  P2  calls  receive  w-ith  parameters,  the  associated  body  with  the 
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handshake  is  executed  by  the  first  process  named  in  the  handshake  (Pi).  Fig¬ 
ure  8.5  shows  handshakes  when  there  is  a  buffer  process  that  can  store  mes¬ 
sages.  For  simplicity,  we  assume  that  the  processes  are  interested  in  communi¬ 
cating  integers  only.  These  examples  illustrate  that  handshake  construct  can 
simulate  messages  easily. 

We  impose  certain  restrictions  on  use  of  the  handshake  construct.  The 
syntax  requires  every  participant  in  the  process  to  be  explicitly  named.  Simi¬ 
larly,  a  handshake  procedure  cannot  be  called  from  within  the  body  of  another 
handshake.  These  restrictions  are  required  for  the  feasibility  of  automatic 
analysis  of  the  communication  structure. 


handshake  syvcsend, 
const 

.M.\XLENG  =  50; 
type 

message  =-  array [1..^LAXLENG]  of  char; 
numbytes  =  O..NL\XLENG; 

procedure  Pl.sc«i/(  senddata:  message;  scount:  numbytes); 
procedure  P2.reren’e(  var  recdata:  message; 

var  rcount;  numbytes); 


var  i;  integer; 

begin 

for  i:=l  to  scount  do 
recdata[i]  :=  senddata(i); 
rcount  :=  scount; 

end; 


Figure  8.4;  Synchronous  Send 
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handshake  put_item, 
procedure  sender. send(sdata;  integer); 
procedure  buffer. ifj«er/(var  bdata;  integer); 
begin 

bdata  :=  sdata; 

end; 

handshake  get^Heni; 
procedure  burrer.remorc(bdata:  integer); 
procedure  receiver. reccire(var  rdata:  integer); 
begin 

rdata  :=  bdata: 

end: 


Figure  8.5:  Asynchronous  Send 

Unit  Specification 

In  the  example  of  distributed  players,  players  may  have  different  con¬ 
straints  on  their  sequence  of  games.  For  example,  Joe  may  wish  to  play  only 
tennis  after  chess.  Similarly,  in  the  example  of  buffered  send,  we  did  not 
specify  the  buffer  process.  If  the  buffer  process  allowed  put,  item  and  get,  item 
in  any  order,  the  communication  may  be  faulty.  A  single-buffer  process 
behaves  correctly  if  it  satisfies  the  constraint  that  a  put, item  is  always  fol¬ 
lowed  by  a  get, item  and  ince-i'ersa.  As  a  result,  the  sender  may  have  to  wait 
for  the  receiver  to  read  an  item  from  the  buffer  process  before  it  sends  another 
item.  To  express  such  constraints  and  therefore  provide  a  high  level  synchroni¬ 
zation  mechanism,  we  provide  the  unit  construct. 

To  describe  all  possible  sequences  of  handshake  procedures,  we  can  use  a 
algebra  based  model  (e  g  regular  expressions)  or  transition  based  model  (e.g. 
finite  state  machines).  The  transition  based  model  has  the  advantage  that  it  is 
is  graphical,  while  the  algebra  based  model  is  sometimes  more  natural  to  the 
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application.  Our  implementation  uses  unit  machines,  the  transition  based 
model,  for  expressing  the  constraints.  We  can  also  use  unit  expressions  because 
a  unit  machine  can  be  converted  to  a  unit  expression  and  vice-versa. 

A  unit  is  a  directed  graph  where  vertices  are  called  places,  and  edges 
between  them  are  labeled  by  names  of  handshakes.  In  addition,  there  is  the 
concept  of  tokens  which  may  be  thought  of  as  residing  in  places.  A  handshake 
can  take  place  only  if  there  is  a  token  in  the  tail  vertex  (source  place)  of  the 
handshake.  After  execution,  the  token  moves  to  the  head  vertex  (destination 
place).  Figure  8.6  shows  the  linguistic  and  graphical  equivalent  of  the  con¬ 
straints  imposed  by  Joe.  Figure  8.7  shows  the  linguistic  and  graphical 
equivalent  of  a  one-frame  buffer.  The  marking  construct  is  used  to  describe 
the  number  of  tokens  at  various  places.  The  body  of  a  unit  consists  of 
enumeration  of  all  transitions  in  the  unit.  These  transitions  are  arranged  on 
the  basis  of  their  source  places.  A  place  name  is  followed  by  the  description  of 
transitions,  each  consisting  of  a  handshake  name  followed  by  the  destination 
place. 


put_i1em 


unavail  avail 
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•  Joe  will  play  only  lennis  after  chess 
-  Joe  will  play  only  bridge  after  tennis 


unit  Joecoirtvr, 
marking  [start:!]; 
begin 
start 

>  chess  estate; 

>  tennis  tstate; 

>  bridge  bstate; 
estate 

>  tennis  tstate; 
tstate 

>  bridge  bstate; 
bstate 

>  tennis  tstate; 

>  chess  estate; 

>  bridge  bstate; 

end; 


Figure  8.6:  Unit  Spceification  for  Joe 

(*  pxit. item  should  be  followed  by  a  get, item 

get,  item  should  be  followed  by  a  put,  item  *) 
unit  buffercomnr, 
marking  [unavail;!]; 
begin 
unavail 

>  put, item  avail; 
avail 

>  get,  item  avail; 

end; 
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Figure  8.7;  Unit  Specification  of  a  One-frame  buffer 


Figure  8.8  presents  the  use  of  *-places  to  specify  the  unbounded  buffer 
problem  in  ConC. 


(*  the  receiver  v^ust  wait  for  the  sender  *) 
unit  buffercomm; 
marking  [unavail:*]; 
begin 
unavail 

>  put, item  avail; 
avail 

>  get,  item  unavail: 

end; 


Figure  8.8;  An  Example  of  the  Unit  Specification 


The  BNF  for  the  specification  of  a  unit  is  as  follows; 


<unit.speos>  :;=  unit  id  <marking> 

{  <tran:.itions>  )  end 
•  <marking>  ::=  marking 

{  ’['  <placename>  <num>  ’]'  } 
<num>  ::=  I  integer 
<transitions>  ;;=  placename 

{  ’>’  transname  placename  } 


3.2.  Guard  Construct 

For  selective  communication,  we  also  assume  that  the  language  has  the 
guarded  command  construct  as  proposed  by  Hoare  for  CSP.  A  guarded  com¬ 
mand  consists  of  one  or  more  <guard,  statement  >  pairs.  A  guard  consists  of 
a  boolean  condition  and  optionally  a  handshake.  The  handshake  is  enabled 
only  if  the  boolean  condition  is  true.  If  an  enabled  handshake  can  be  executed 
(participating  processes  are  willing  to  execute  the  handshake),  the  guard  is 
considered  true  and  the  statement  corresponding  to  the  guard  can  be  executed. 
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The  syntax  of  the  guard  construct  is  as  follows: 


<guarded. command>;:  ’{’  <guard>  <statement>  ’]’ 

< guard >::  < boolean. condition >  handshakeid 

For  an  example  of  guard  construct,  consider  the  buffer  process  which  may 
comrhunicate  with  either  the  sender  or  the  receiver.  Its  specification  is  as  fol¬ 
lows; 

int  findex  =  0; 
int  bindex  =  1; 

[ 

put. item  ->  insert(ilem); 

findex  =  (findex  +  1)  mod  size; 
bufrarray[findex]  =  item; 
get. item  ->  remove(bufrarray[bindex)); 

bindex  =  (bindex  +  1)  mod  size; 

] 


3.3.  Mutual  Exclusion  between  Two  Processes 

As  an  example  of  these  constructs,  consider  the  mutual  exclusion  between 
two  processes  X  and  Y.  The  entire  system  has  four  handshakes  -  plin,  plout, 
p2in,  p2out.  Plin  handshake  requires  participation  from  both  the  processes  X 
and  Y.  This  is  specified  in  the  handshake  declaration  of  plin.  Plout,  on  the 
other  hand,  does  not  need  any  coordination  from  the  process  Y.  The  unit  con¬ 
struct  allows  p2in  to  happen  only  if  the  process  X  is  in  a  non-critical  state. 
The  entire  specificaticm  of  the  process  X  is  given  in  Figure  8.9. 
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handshake  pitn, 

procedure  X.plin{); 
procedure  Y.plin()\ 
begin 
end; 

handshake  plout\ 

procedure  X.piot//(); 
begin 
end; 

(*  communication  unit  for  process  X  *) 
unit  mutexl; 
marking[noncritical:J]; 
noncritical  ; 

>  plin  critical; 

>  p2in  noncritical; 
critical  ; 

>  plout  noncritical  ; 

end; 

(*  infernal  computation  for  process  X  *} 
niainO 
{ 

inf  i; 

for  (i=l;  i<  =  10;  i++) 

{ 

plin(); 

(*  this  is  the  critical  region  *) 
plout( ); 

} 


Figure  8.9;  Mutual  Exclusion  Betxveen  Two  Processes 


3.4.  Dining  Philosophers 

A  deadlock  free  solution  to  the  dining  philosopher  problem  (discussed  in 
Section  7.3.3)  expressed  in  ConC  is  shown  in  Figure  8.10.  ye/,  ,-^j  represents 
that  philosopher  has  taken  possession  of  t  +  l'^  fork.  The  philosopher^  does 
not  seek  possession  of  i  +  l*^  fork  unless  it  also  possesses  fork.  Note  the 
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simplicity  of  the  solution  due  to  the  availability  of  synchronous  communica¬ 
tion. 


handshake  +  i 
procedure  philosopher^. get^ 
procedure  philosopheri^yget^.^^^-, 

begin 

end; 

unit  philunit^\ 

markingjneutral:!]; 

neutral 

>  eating  ; 

>  waiting; 
eating 

>  neutral; 
waiting 

>  P^U-\,i  neutral; 

end  ; 

process  philosopher^; 

begin 

if  hungry  then  begin 

eat(); 

P^f{.x+\(h 

end; 

end; 

Figure  8.10;  A  Solution  To  Dining  Philosophers  Problem 
Having  stated  a  solution  to  the  dining  philosophers  problem,  we  would  like  to 
verify  that  our  solution  is  indeed  deadlock  free.  Current  programming  systems 
typically  require  manual  analysis  for  such  questions.  As  we  staled  earlier,  one 
of  our  aim  is  to  automatically  analyze  specifications  expressed  in  handshake 
and  unit  constructs.  We  can  do  so  because  these  constructs  are  based  on  the 
STOCS  Model. 
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4.  Interaction  between  Computation  and  Communication  Objects 

Each  logical  process  is  actually  composed  of  two  real  processes:  computa¬ 
tion  and  communication  process.  The  computation  process  communicates  only 
with  its  communication  process,  which  in  turn  communicates  with  other  com¬ 
munication  processes.  Therefore,  the  actual  communication  between  various 
processes  is  as  shown  in  Figure  8.11. 


Figure  8.11;  Communication  Structure  of  ConC  programs 
The  computation  process  interacts  with  communication  process  by  two  means: 

(1)  Simple  handshake  call:  As  seen  earlier  the  execution  of  a  handshake  may 
require  the  participation  of  multiple  processes.  The  computation  process  sends 
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an  enable  message  to  the  communication  process  whenever  it  is  ready  for  a 
particular  handshake  and  waits  for  a  reply  from  it.  The  communication  pro¬ 
cess  goes  through  a  series  of  protocol  messages  with  other  communication 
processes  to  agree  on  the  execution  of  the  handshake,  if  it  succeeds,  it  tells  the 
computation  process  to  proceed  and  send  the  relevant  message  to  the  master 
of  the  handshake.  If  the  handshake  is  not  possible  because  one  of  the  par- 
ticpant  process  has  terminated  then  the  communication  process  sends  an  error 
message  to  the  computation  process. 

(2)  Calls  from  Guard:  Since  only  one  handshake  is  allowed  in  every  guarded 
statement,  we  conclude  that  if  all  participant  processes  are  ready  for  a 
handshake  it  can  be  always  be  executed,  even  if  the  handshake  call  is  from  a 
guard.  The  computation  process  enables  all  the  handshakes  that  are  called 
from  the  conditions  of  the  guarded  statements.  It  then  waits  for  a  reply  from 
the  communication  process.  The  communication  process  sends  to  the  compu¬ 
tation  process,  the  name  of  the  handshake  it  has  committed.  It  is  the  responsi¬ 
bility  of  the  computation  process  to  execute  the  handshake. 

6.  Implementation  of  the  ConC  System 

The  current  ConC  system  consists  of  two  sub-systems:  ConC  iranslaior, 
and  STOCS  analyzer.  ConC  translator  generates  a  set  of  "C”  processes  from  a 
ConC  program.  These  processes  communicate  using  the  semantics  of  a  syn¬ 
chronous  handshake  in  STOCS.  The  execution  of  a  handshake  requires  syn¬ 
chronization  between  multiple  processes  similar  to  that  required  by  a  general¬ 
ized  CSP  alternative  command.  Chapter  9  describes  an  algorithm  for  multi- 
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Deadlock  errors 

Figure  8.12:  The  Architecture  of  ConC  System 
pro(e>>  synchronous  communication.  ConC  Translator  is  implemented  on 
SUN  workstations  with  4.2  BSD  UNK.  STOCS  analyzer  analyzes  a  given 
STOCS  for  the  following  type  of  queries:  Is  configuration  Cl  reachable?  Is 
there  any  configuration  with  no  exits?(potential  deadlocks)  It  is  written  in 
Franzlisp  and  runs  on  4.3  BSD  UNTX. 


6.  Conclusions 

This  chapter  presents  two  new  constructs  to  support  distributed  computa¬ 
tion  -  handshake  and  unit.  The  handshake  construct  is  a  multi-process  gen- 
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eralization  of  the  RPC.  The  unit  construct  is  used  to  specify  the  possible 
sequences  of  handshakes  and  thereby  provide  a  synchronization  mechanism 
between  multiple  processes.  These  constructs  unify  a  large  number  of  con¬ 
cepts,  such  as  semaphores,  monitors,  path  expressions,  input/output,  remote 
procedure  calls  and  communication  abstraction.  These  constructs  are  based 
on  a  formal  model  called  the  STOCS  model  which  is  mechanically  analyzable. 
The  analysis  can  be  done  with  respect  to  reachable  configurations  of  a  STOCS 
machine  and  the  language  accepted  by  it. 

The  proposal  for  ConC  is  unique  in  that  it  combines  aspects  from  diverse 
languages  such  as  CSP,  Ada,  SCRIPT,  Path  Pascal,  Raddle  and  PPSA.  The 
theory  combines  aspects  from  algebraic  theory,  net  theory  and  formal 
language  theory. 
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CHAPTER  9 


Execution  of  STOCS  Machines 

1.  Introduction 

The  STOCS  model  is  based  on  the  concept  of  handshake,  a  shared  event. 
Therefore,  to  execute  a  STOCS  machine,  we  need  a  mechanism  for  implement¬ 
ing  shared  events.  Execution  of  shared  events  is  required  in  general  by  distri¬ 
buted  systems  which  often  need  tricky  synchronization  between  multiple 
processes.  Example  of  such  shared  events  are;  (1)  distributed  transactions  in 
databases  that  require  commit  by  either  all  or  none  of  the  processes  (2)  atomic 
broadcasts  that  require  that  a  message  be  received  by  either  all  or  none  of  the 
receivers.  Shared  event  is  such  an  useful  concept  that  it  is  not  surprising  that 
it  appears  in  coupled  state  machines,  Petri  Nets,  CSP  and  CCS.  Ease  in 
specification  of  concurrent  systems  using  the  concept  of  shared  event  provides 
a  strong  motivation  for  the  search  of  an  efficient  algorithm  for  its  execution. 

Multi-process  shared  event  execution  problem  is  as  follows.  Let  there  be  n 
geographically  distributed  processes.  Each  process  is  either  waiting  for  some 
event  or  executing.  An  event  may  require  cooperation  of  two  or  more 
processes.  Each  process  when  idle  is  willing  to  embark  on  any  of  the  event  that 
is  enabled  in  its  current  state.  We  assume  that  processes  can  communicate 
with  each  other  asynchronously  by  means  of  reliable  messages.  We  have  to 
design  an  algorithm  for  executing  shared  events  between  these  processes. 

A«  ?n  ey'>»^p>“  this  problem  in  real  life,  consider  the  distributed  players 
problem.  Assume  that  there  are  four  players  who  are  interested  in  playing 
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various  games  as  shown  in  Figure  9.1.  Joe  is  willing  to  play  chess,  bridge  or 
poker.  Mary  is  willing  to  play  any  of  the  games  while  Jack  and  Bob  play  only 
bridge  or  poker.  Joe  in  state  S2  Play  only  tennis  and  only  bridge  in  state 
S3.  Similarly,  Mary  plays  only  poker/tennis  if  she  is  in  state  S2  and 
chess/bridge  if  in  state  S3.  Since  games  require  cooperation  between  two  or 
more  players  the  players  may  have  to  wait  for  each  other.  Also  the  players 
are  in  different  cities  (i.e.  on  different  processors)  and  can  communicate  only 
through  mail  (asynchronous  messages). 


Figure  9.1;  Distributed  Player  Problem 

Our  algorithm  makes  following  assumption  on  the  communication  net¬ 
work: 

(1)  Reliable  Messages:  The  algorithm  assumes  that  all  messages  sent  by 
one  machine  to  another  are  received  uncorrupted  in  proper  order.  A  ser¬ 
vice  can  easily  be  provided  by  a  communication  protocol  layer  that 
detects  duplicate,  lost,  out-of-sequence  and  corrupt  messages. 
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(2)  Clock  Synch''onization;  The  algorithm  assumes  that  local  and  global 
causality  as  proposed  by  Lamport  is  preserved  by  clocks  of  various 
machines.  This  can  easily  be  provided  by  an  extra  layer  of  clock  syn¬ 
chronization  that  uses  Lamport’s  algorithm. 

This  chapter  is  organized  as  follows.  Section  2  describes  the  related  work 
in  execution  of  shared  events.  Section  3  presents  our  algorithm  for  the  execu¬ 
tion.  Section  4  describes  the  message  complexity  of  the  algorithm.  Section  5 
proves  its  correctness.  Section  6  explores  some  efficiency  considerations  of  the 
algorithm. 


2.  Related  Work 

The  execution  of  shared  events  also  arises  in  implementation  of  the  gen¬ 
eralized  I/O  command  of  CSP.  A  CSP  program,  as  described  in  [Buckley  83), 
consists  of  a  set  of  processes  that  communicate  with  each  other  using  syn¬ 
chronized  message  passing.  Communication  between  processes  occur  when  two 
processes  have  matching  input  and  output  statements.  The  alternative  com¬ 
mand  of  CSP  provides  non-determinism  by  letting  a  process  select  one  of  the 
several  statements  for  processing.  Each  statement  is  protected  by  a  guard  (a 
boolean  expression  and/or  one  input  statement)  w'hich  must  be  enabled  for  the 
statement  to  be  considered  for  selection.  A  guard  is  enabled  if  the  boolean 
expression  evaluates  to  true  and  the  named  output  process  has  not  terminated. 
However,  not  all  algorithms  are  easy  to  express  using  only  the  constructs  of 
CSP.  Researchers  have  found  it  useful  to  extend  the  notion  of  guard  to 
include  output  command  and  many  implementations  have  been  presented 
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[Buckley  83,  Bagrodia  86,  Ramesh  87,  Lee  87,  Natrajan  86).  This  generalized 
CSP  construct  is  obviously  a  special  case  of  multi-process  synchronous  events 
problem. 

[Buckley  83]  presented  four  conditions  that  should  be  satisfied  by  an 
effective  implementation  of  the  CSP  I/O  construct.  They  showed  that  [Silber- 
schatz  79,  Snepscheut  81]  did  not  satisfy  one  or  more  of  these  conditions. 
[Back  84]  improved  upon  this  result  by  providing  an  implementation  that 
satisfied  two  more  conditions.  [Ramesh  87]  provided  an  improved  implementa¬ 
tion  which  could  be  extended  to  allow  multi  process  synchronization.  We  pro¬ 
vide  a  new  distributed  algorithm  that  has  following  distinguishing  features 
from  rest  of  the  work:  Our  algorithm  satisfies  all  six  conditions,  shows  strong 
fairness  and  is  extensible  to  the  case  of  multi-process  synchronization.  In  addi¬ 
tion,  it  is  simpler  than  algorithms  presented  in  ljterature[Buckley  83,  Silber- 
schatz  79].  We  present  in  this  chapter  our  algorithm,  a  proof  of  its  correctness, 
its  message  and  time  complexity.  The  proposed  algorithm  differs  from  its 
predecessor  [Ramesh  87]  (referred  to  as  Rl  in  subsequent  discussion)  which 
shares  the  advantage  of  multiprocess  synchronization  in  the  following  ways; 

(1)  Sequential  Capturing;  In  Rl,  a  process  captures  all  processes  partici¬ 
pating  in  an  events  sequentially  to  avoid  any  deadlock.  This  can  result  in 
a  substantial  delay  for  events  that  is  shared  by  a  large  number  of 
processes.  Since  processes  are  captured  for  a  long  time  it  also  means  that 
other  processes  may  have  to  wait  for  a  long  time  for  captured  processes  to 
be  released.  In  our  algorithm,  a  process  tries  to  capture  all  participating 
processes  in  parallel. 
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(2)  Message  Load:  In  Rl,  no  specific  process  is  assigned  as  a  master  of  a 
handshake.  This  makes  the  algorithm  look  completely  distributed  at  a 
superficial  level  by  making  every  process  do  the  work  of  master.  Thus,  if 
a  handshake  is  shared  by  m  processes,  each  of  them  may  have  to  do 
0(77j)  amount  of  work  for  that  handshake.  We,  on  the  other  hand,  assign 
a  master  for  each  handshake,  thus  simplifying  the  algorithm  and  reducing 
the  message  load.  We  also  provide  algorithm  for  assignment  of  this  coor¬ 
dination  such  that  the  maximum  load  on  any  single  process  is  minimized. 

(3)  Fairness  in  Execution:  In  Rl,  a  guard  is  chosen  at  random  by  each 
process  thereby  guaranteeing  that  any  guard  has  finite  probability  of 
being  chosen.  We,  provide  a  stronger  fairness  in  the  sense  that  we  chose  a 
handshake  which  is  coordinated  by  a  master  for  the  longest  time.  Our 
definition  of  fairness  implies  fairness  proposed  by  Rl. 

(4)  Timestamped  Messages:  Rl  does  not  use  timestamps  in  its  algorithm. 
Our  algorithm  requires  global  causality  of  timestamps  and  we  assume  that 
there  is  a  clock  synchronization  algorithm  such  as  proposed  by 
Lamport  [Lamport  78]  running  on  the  network.  Since  Lamport’s  algo¬ 
rithm  is  very  simple  to  implement  and  does  not  incur  high  penalty,  this  is 
a  not  a  serious  drawback  of  our  algorithm.  Besides,  due  to  usefulness  of 
global  causality  other  algorithms  may  already  be  using  a  clock  synchroni¬ 
zation  algorithm.  Timestamps  are  also  useful  in  ignoring  outdated  mes¬ 
sage. 

(5)  Ready  Message:  We  use  a  set  of  messages  called  ready  messages  which 
increase  the  probability  that  a  request  message  succeeds.  If  a  participant 


169 


of  a  handshake  sends  a  ready  message  to  the  master,  he  is  marked  as 
ready  in  a  table.  For  performance  reasons,  we  do  not  require  processes  to 
send  ”not-ready”  messages  when  they  are  not  ready  for  a  handshake. 
Thus,  an  entry  in  a  ready  table  can  be  treated  only  as  a  hint.  If  it  indi¬ 
cates  that  a  process  is  not  ready  for  a  handshake  then  this  is  true  for  the 
steady  state  of  the  system.  However,  if  it  says  that  a  process  is  ready  for 
some  handshake  then  this  must  be  confirmed  by  a  request  message. 

3.  Description  of  the  Algorithm 

Informally,  the  algorithm  is  as  follows.  Each  handshake  is  assigned  a 
master.  A  master  can  execute  a  handshake  if  all  participating  processes  com¬ 
mit  to  it.  A  process  can  commit  to  a  handshake  by  sending  a  yes  message  to 
its  master.  A  master  requests  for  these  messages  by  means  of  request  messages. 
A  request  message  may  be  either  be  delayed  or  responded  with  a  yes  message, 
or  a  no  message.  If  all  the  participating  processes  commit  the  master  sends  a 
success  message  to  them.  On  receiving  a  success  message,  a  process  can  exe¬ 
cute  the  handshake. 

When  a  process  is  in  execution  state  (executing  some  handshake),  it 
responds  to  only  two  kinds  of  messages-  ready  and  request.  For  ready  message 
it  makes  a  note  in  its  ready  table  whereas  a  request  message  is  replied  by  a  no. 

Once  a  process  comes  to  an  alternative  command  it  first  sends  ready  mes¬ 
sage  to  all  the  masters  for  the  guard  it  is  ready  to  execute.  Then  if  any  transi¬ 
tion  is  ready  and  it  sends  out  request  messages.  After  this  the  process  takes  an 
action  only  on  receiving  a  message. 
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Some  of  the  features  of  this  algorithm  are  as  follows: 

(1)  A  process  can  send  a  yes  message  to  at  most  one  master.  Thus,  a  process 
commits  to  at  most  one  master.  A  process  that  has  committed  to  a 
handshake  can  not  send  request  message  for  any  other  handshake.  This 
way  of  committing  resembles  two-phase  commit  protocol  used  in  data¬ 
bases  for  implementing  transactions.  The  difference  between  two  problems 
is  that  in  databases  if  two  transactions  and  are  eligible  at  some  state, 
then  the  protocol  needs  to  ensure  that  the  final  execution  can  be  written 
either  as  or  <2^1-  If'  problem,  once  a  /  j  is  executed  /2  may  not  be 
valid  any  more.  For  example,  initially  both  tennis  and  chess  may  be  eligi¬ 
ble,  but  once  tennis  is  played  chess  may  not  be  eligible  anymore, 

(2)  A  process  that  has  already  committed,  on  receiving  a  request  for  another 
handshake,  says  no  to  a  younger  process  and  delays  the  older  process.  If 
the  process  is  the  master  of  its  committed  handshake  and  the  handshake 
has  not  received  all  the  yes  messages  then  it  is  aborted  in  favor  of  an 
older  handshake.  This  way  there  cannot  be  any  deadlock  between 
different  handshakes.  This  strategj'  is  commonly  referred  as  wait  die  stra- 
teg)’  in  databases  as  discussed  in  (Eswaran  76]. 

(3)  Processes  always  include  the  timestamp  of  the  handshake  they  are 
responding  to.  This  has  the  advantage  that  the  messages  that  are  obsolete 
can  be  detected  and  therefore  ignored. 

(4)  The  fairness  is  based  on  the  principle  of  serving  the  master  w-ho  has 
served  the  longer.  With  each  request  message  for  a  handshake,  the  master 
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sends  the  lime  of  the  event  it  coordinated  before. 

The  algorithm  as  shown  in  Figure  9.2  use  the  following  messages: 

ready: 

sent  by  a  process  to  the  master  of  a  handshake  indicating  its  willingness 
to  execute  the  handshake  This  message  can  be  sent  to  multiple  masters. 

request: 

sent  by  the  master  to  processes  for  the  yes/no  reply,  With  a  request  mes¬ 
sage,  the  master  also  sends  the  time  of  the  last  shared  event  it  executed  as 
a  master. 

yes:  sent  by  a  process  to  the  master  of  a  handshake  indicating  its  willingness 
to  execute  the  handshake.  This  message  is  sent  to  only  one  master. 

no:  sent  by  a  process  to  the  master  of  a  handshake  indicating  that  it  has  com¬ 
mitted  for  some  other  handshake 

success: 

sent  by  the  master  to  processes  asking  them  to  execute  the  handshake 

abort: 

sent  by  the  master  to  processes  asking  them  to  abort  the  handshake 
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Background() 

if  (mtype  =  ready)  update (ready. table) 
else  if  (mtype  =  request)  reply (currsess,  uo) ; 

InitlaliieO 

captured  =  0;  delayed[  ]=0;  initialize.gnards; 

send  ready  aesEages  to  various  masters; 

if  any  transition  is  ready  then  seinjrequestrCaytrans) ; 

Handle.  Ready  0 

update (ready. table) ; 

if  (the  transition  is  ready)  and 

(I  am  not  exploring  any  other  transition)  then  sendrequest; 
Handle.RequestO 

if  (guard [tran8]=closed)  reply (curraess,  no); 
else  if  (aytrans  =  0)  /*  I  am  not  committed  */ 
aytran8:=tran8; 
reply (curraess.  yes); 

else  if  (tiaestaap [trass]  >  timestamp [captured]) 
reply (curraess,  no); 
el«e  if  (master [captured]  =  ayid) 
sendabort (aytrans) ; 
aytrans  =  trans; 
reply (curraess,  yes); 
else  delayed [curraess . 8rc]=trans ; 

Handle.  Abort() 

try.another. transition; 

Handle.Succ() 

if  (captured  =  curraess. trans) 
taketran8(  curraess. trans); 

Handle.YesO 

checklist [curraess . src]=0; 
if  all.have.responded.yes 

taketrans (curraess. trans) ; 
sendsucc (curraess . trans) ; 

Handle.  NoQ 

rstatus [trans] [src]  =  false; 

sendabort(trans) ; 

try. another. transition; 

try.  another.  trans!tion() 

if  any  process  delayed  respond  to  it; 

else  if  any  transition  ready  send  request 

else  send  ready  to  aasters  sbich  have  been  sent  no 


Figure  9.2:  Algorithm  for  Execution  of  Multi-process  Events 
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Some  of  the  data  structures  are  as  follows: 

ready,  table;  a  table  maintained  by  the  master  of  a  handshake.  As  explained 
earlier,  this  table  is  only  one  way  correct. 

delayed,  list:  list  of  all  masters  that  have  been  delayed  by  me. 
guard  [handshake];  Is  the  handshake  enabled  in  my  current  state, 
captured:  master  that  has  captured  me 

4.  Message  Complexity 

77) e  Worst  Case 

We  will  calculate  the  number  of  messages  a  process  has  to  handle  in  the 
worst  case  before  it  is  guaranteed  to  succeed.  We  first  calculate  the  number  of 
times  a  handshake  can  abort.  By  our  fairness  rule,  a  process  can  be  aborted  in 
favor  of  some  other  process  at  most  once.  Thus,  if  there  are  p  processes  which 
are  master  of  some  handshake,  then  a  handshake  of  the  process  must  succeed 
after  p  — 1  or  less  number  of  attempts.  Hence,  the  number  of  requests  to  a  pro¬ 
cess  for  a  guard  is  less  than  or  equal  to  p  — 1  and  correspondingly  the  number 
of  aborts  is  less  than  or  equal  to  p— 2.  There  is  at  most  one  success  message. 
Therefore,  the  number  of  messages  in  the  worst  ca^e  for  a  master  guard  with  d 
slaves  to  succeed  in  executing  a  handshake  is: 

ready  messages  at  most  (p  — l)d  in  number 

request  message  at  most  {p  —  l)d  in  number 

no  at  most  (p  —  l)d  in  number 

yes  at  most  (p  —  l)d  in  number 

abort  at  most  (p—2)d  in  number 

succeed  at  most  d 

Total:  S(p  —  \)d  messages 
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The  Best  Case 


In  the  best  case,  there  will  be  no  aborts;  therefore,  a  master  guard  will  be 
successful  in  4rf  messages.  A  slave  guard  will  require  four  messages  for  suc¬ 
cessful  execution  of  a  handshake. 

5.  Correctness  of  the  algorithm 

In  this  section,  we  prove  that  the  algorithm  shown  in  Figure  9.2  is  correct. 
The  correctness  of  the  algorithm  is  shown  in  two  parts.  We  show^  that  the 
algorithm  is  safe,  that  is  it  can  ask  a  process  to  participate  in  at  most  one 
handshake.  We  also  show  that  the  algorithm  is  live,  that  is  if  one  or  more 
handshakes  are  enabled,  the  system  will  execute  some  handshake. 

5.1.  Safety  Property 

Theorem  9.1;  Each  process  can  be  asked  to  participate  in  at  most  one 
handshake. 

Proof:  A  process  commits  for  a  handshake  only  if  it  has  sent  yes  in  response 
for  the  handshake  or  it  is  master  for  that  handshake  and  has  sent  request  mes¬ 
sages.  Since  a  process  can  have  at  most  one  outstanding  yes  message  if  it  has 
not  sent  out  any  request  message  and  none  if  it  has  sent,  a  process  cannot 
commit  for  two  handshakes.  Q.E.D. 

5.2.  Liveness  Property 

Theorem  9.2:  If  one  or  more  handshakes  are  eligible  then  the  system  will 
execute  a  handshake. 
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Proof;  Consider  the  master  of  the  handshake  who  has  waited  for  the  longest 
time.  When  this  master  sends  out  the  request  message,  if  all  processes  respond 
with  yes,  the  handshake  can  be  executed.  Since  the  handshake  is  eligible  and 
has  the  highest  priority,  no  process  can  send  no  for  the  handshake.  The  only 
other  option  for  them  is  to  delay  their  response. 

We  define  the  delay  graph  D  as  a  directed  graph  D  =  (V,  E)  where  V  is 
the  set  of  all  the  processes.  There  is  a  directed  edge  from  process  to  V2  if 
there  exists  a  process  that  has  delayed  in  favor  of  ^2-  This  implies  that  the 
priority  of  I’j  is  greater  than  because  we  delay  the  older  process.  Global 
causality  implies  that  the  graph  is  acyclic.  We  traverse  the  path  of  processes  in 
the  delay  graph.  Since  the  delay  graph  is  acyclic,  we  will  reach  a  node  which 
has  no  outgoing  edge.  This  process  being  youngest  will  receive  answer  from  all 
the  processes  and  therefore  can  send  success / abort  message  to  all  its  processes 
in  its  set  which  then  can  reply  to  their  delayed  masters.  If  the  decision  was 
abort  then  the  path  delay  graph  has  less  number  of  edges  and  this  particular 
handshake  will  not  be  explored  again.  If  the  decision  was  success,  a  handshake 
is  executed.  Q.E.D. 

For  example,  consider  the  example  of  distributed  players.  Let  Joe  be  the 
master  of  tennis,  Mary  of  chess.  Bob  of  poker  and  Jack  of  bridge.  Let  the  last 
time  each  game  was  played  be  as  follows: 

Tennis  12 
Chess  15 
Poker  14 
Bridge  18 

Assume  that  tennis  is  eligible  because  all  participating  players  are  willing  to 
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play  it.  Assume  the  Bob  and  Mary  are  willing  to  play  poker  but  Jack  is  not. 
Consider  the  following  event  sequence; 

(1)  Bob  sends  a  request  to  Mary  for  poker  who  responds  yes  as  she  has  not 
committed  to  any  other  game. 

(2)  Joe  sends  request  for  tennis  to  Mary  who  delays  the  response  to  this  mes¬ 
sage. 

(3)  Bob  sends  request  for  poker  to  Jack  who  responds  with  a  no  message. 

(4)  Bob  sends  abort  for  poker  to  Mary,  who  now  can  respond  to  the  delayed 
request  of  Joe. 

(5)  Joe  can  now  send  success  message  to  Mary,  who  then  can  execute  the 
handshake. 

5.3.  Effective  Implementation 

Theorem  9.3:  The  algorithm  satisfy  all  the  six  criteria  of  effective  implemen¬ 
tation  as  proposed  by  [Buckley  83]  and  extended  by  [Back  84,  Ramesh  87). 
The  six  criteria  are  as  follows. 

(1)  The  number  of  processes  that  are  involved  in  the  selection  of  a  guard 
should  be  minimum. 

(2)  The  amount  of  system  information  that  each  of  these  processes  should  be 
low. 

(3)  When  a  handshake  is  ready  then  it  will  be  selected  within  a  finite  time. 

(4)  The  number  of  messages  exchanged  for  making  a  selection  by  any  process 
is  small. 

(5)  The  time  it  takes  for  a  process  to  determine  whether  it  can  establish  com- 
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munication  with  some  other  process  should  be  bounded. 

(6)  If  a  process  has  a  guarded  command  that  is  infinitely  often  enabled,  then  it 
should  eventually  succeed. 

Proof:  (1)  and  (2)  are  obvious  from  the  algorithm.  (3),  (4)  and  (5)  follows 
from  Theorem  9.2  and  the  message  complexity  analysis.  (6)  follows  from  our 
fairness  conditions.  Q.E.D. 

6.  Efficiency  Considerations  of  the  Algorithm 

In  the  above  algorithm,  we  did  not  discuss  how  we  chose  masters  for  each 
handshake.  The  efficiency  of  the  algorithm  is  dependent  on  this  choice.  We 
discuss  some  desirable  requirements  for  the  choice  and  strategies  to  assign 
masters  based  on  the  requirements. 

6.1.  Minimum  Maximum  load  of  any  node 

The  algorithm,  as  presented  above,  is  unfair  with  respect  to  the  master  of 
the  handshake  who  may  have  to  deal  with  more  messages  than  other  partici¬ 
pating  processes.  To  prevent  any  machine  from  getting  overloaded,  we  may 
choose  masters  such  that  the  maximum  load  on  any  machine  is  minimized. 
The  problem  can  be  stated  formally  as  follows:  Let  A/  and  H  represent  the  set 
of  machines  and  the  set  of  handshakes  respectively.  Let  the  degree  of  a 
handshake  h  be  the  number  of  machines  which  participate  in  it.  Our  problem 
is  to  find  an  assignment  of  master  for  hanshakes,  f  such  that  the  max¬ 

imum  load  on  any  machine  is  minimized.  The  load  of  a  machine  is  defined  as 
the  sum  of  degrees  of  all  handshakes  for  which  it  acts  as  a  master.  For  exam¬ 
ple,  consider  the  example  in  Figure  9.1.  The  degree  of  various  handshakes  is 
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as  follows; 


Chess:  2 
Tennis;  2 
Poker;  3 
Bridge:  4 

A  possible  master  assignment  is  as  follows: 

Chess,  Poker;  Mary 
Tennis;  Joe 
Bridge:  Jack 

The  maximum  load  in  this  assignment  is  on  Mary  who  has  to  the  load  of  Chess 
(2)  and  Poker  (3).  If  Bob  is  assigned  as  the  master  of  Poker,  then  Jack  will 
have  the  maximum  load  of  Bridge  (4). 


Theorem  9.4;  Let  there  be  m  machines  and  n  handshakes.  There  exists 
an  algorithm  with  0(log(wn)w'n")  time  to  find  the  master  assignment  f;H- 
>M,  such  that  the  maximum  load  on  any  machine  is  minimized. 

Proof;  \\’e  consider  a  related  problem  which  seeks  the  assignment  of  masters 
such  that  the  maximum  load  on  any  machine  is  less  than  K.  Let  the  total  load 
(the  sum  of  degree  of  handshakes)  be  S. 


(11,11) 


Figure  9.3:  Minimizing  the  Maximum  Load 
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This  problem  can  be  solved  as  feasible  circulation  in  a  network  with  upper  as 
well  as  lower  bounds  on  the  capacity  of  each  edge.  We  add  a  pseudo  source  s 
and  a  pseudo  sink  t  with  the  following  bounds: 

l(s  J}^)=u[s  ,hi)=l(h-,ni  ^■)=u{h-,m^)=degree(hi) 

l(m-,t)=0-,'u{m-,t)=K ,l{t,s)=S,u(t,s)=S  \fhieH, 

Figure  9.3  shows  the  assignments  to  various  edges.  Using  Out-of-Kilter 
method[Lawler  76],  this  problem  can  be  solved  in  0(m^n“)  where  m  is  the 
number  of  machines  and  n  is  the  number  of  handshakes.  Using  the  solution  to 
decision  problem,  we  can  solve  the  minimization  problem  in  0(log[mn))  time 
using  a  binary  search.  Thus,  the  problem  of  finding  master  assignment  such 
that  the  maximum  load  on  any  machine  is  minimized  can  be  solved  in 
O[log[mn  ]m“n"). 

6.2.  Minimum  Total  Number  of  Messages 

An  alternative  optimization  criterion  could  be  the  minimization  of  the 
number  of  messages  required  in  the  overall  system.  As  shown  for  the  calcula¬ 
tion  of  the  message  complexity  of  the  algorithm,  the  number  of  aborts  are 
minimum  if  the  number  of  processes  acting  as  master  is  minimum.  This  is  easy 
to  see  intuitively.  If  there  are  more  processes  that  can  act  as  master,  there  are 
greater  chances  that  these  processes  will  attempt  a  handshake  which  requires  a 
common  process  and  therefore  some  of  them  will  be  aborted.  In  the  limiting 
case,  (that  is  if  we  were  allowed  to  have  just  one  global  master),  there  will  be 
no  aborts.  This  extreme,  however,  violates  our  condition  on  effective  imple¬ 
mentation  M'bich  requires  that  the  number  of  processes  involved  in  deciding  if 
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a  handshake  should  be  executed  must  be  minimum.  Thus,  our  aim  is  to 
minimize  the  number  of  masters  with  the  condition  that  the  master  must  be 
one  of  the  participants  for  the  handshake.  Unfortunately  this  problem  is  NP- 
complete  as  shown  by  Theorem  9.5. 

Theorem  9.5:  The  master  assignment  problem  such  that  the  number  of  mas¬ 
ters  is  miniminzed  is  NP-complete  even  for  the  case  where  each  handshake  is 
shared  by  exactly  two  processes. 

Proof:  We  reduce  the  vertex  cover  problem  known  to  be  NP-complete  to  mas¬ 
ter  assignment  problem  by  treating  vertices  as  processes  and  undirected  edges 
as  handshakes  between  these  processes.  The  vertex  cover  problem  is  as  follows: 

Instance:  Graph  (7=(U,£'),  positive  integer  A'<  1  U|  . 

Question:  Is  there  a  vertex  cover  of  size  K  or  less  for  G,  i.e.  a  subset 
with  W\  <K  such  that  for  each  edge  {v,v}eE  at  least  one  of  u  and  i' 
belongs  to  VV 

We  reduce  each  edge  {u,i'}  to  a  handshake  between  machine  u  and  v.  If 
this  handshake  is  assigned  to  it  then  we  include  u  in  V’  and  vice-versa.  Q.E.D, 

Since  the  number  of  processes  may  not  be  very  large  and  the  computation 
of  master  is  done  only  once,  it  may  still  be  feasible  to  compute  the  optimal 
master  assignment.  However,  since  the  number  of  processes  may  not  be  very 
large  and  the  computation  of  master  is  done  only  once,  it  may  still  be  feasible 
to  compute  the  optimal  master  assignment. 
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7.  Conclusions 


We  have  proposed  an  efficient  implementation  of  the  shared  events  in  a 
distributed  environment.  Our  solution  can  be  used  to  execute  STOCS 
machines  (and  therefore,  also  Petri  nets).  It  is  also  applicable  for  implementa¬ 
tion  of  the  generalized  CSP  I/O  command.  Our  algorithm  is  conceptually 
simpler  and  more  efficient  than  existing  algorithms. 


182 


CHAPTER  10 


Conclusions 


1.  Summary  of  the  Work 

In  this  rejx)n,  we  have  tackled  the  problem  of  formal  specification 

and  analysis  of  message  based  asynchronous  concurrent  systems.  We  have 
defined  a  new  model  of  concurrent  computation  called  the  Synchronous  Token 
based  Communicating  State  (STOCS)  Model.  The  STOCS  model  combines 
the  advantages  of  net-theoretic  and  algebraic  approaches  for  the  study  of  con¬ 
current  systems.  It  is  amenable  to  net-theoretic  analysis  because  the  reacha¬ 
bility  problem  in  a  Petri  net  is  reducible  to  that  in  a  a  STOCS  machine  and 
vice-versa.  It  is  easier  to  use  than  Petri  nets  as  it  supports  modularity  in 
specification  and  analysis.  For  example,  we  have  shown  that  analysis  of  safety 
properties  can  avoid  searching  global  state  space  by  considering  only  the 
relevant  modules.  To  show  that  the  model  also  supports  algebraic 
specification,  we  prove  that  STOCS  machines  can  be  characterized  by  con¬ 
current  regular  expressions.  Concurrent  regular  expressions  extend  classical 
regular  expressions  with  three  operators  -  interleaving,  alpha  closure  and  syn¬ 
chronous  composition.  As  an  application  of  this  result,  we  provide  an  algebraic 
characterization  of  Petri  net  languages. 

Based  on  the  STOCS  model,  we  propose  two  new  constructs,  handshake 
and  unit,  to  support  concurrent  computation.  The  handshake  construct  is  a 
generalized  remote  procedure  call  for  multiple  parties.  The  unit  expression  is  a 
generalized  path  expression  which  provides  conditional  synchronization  by 
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restricting  the  possible  sequence  of  calls  to  handshakes.  Any  program  that  has 
its  communication  aspects  specified  using  these  constructs  can  be  analyzed  for 
logical  correctness  of  its  communication.  We  have  developed  a  fair  and 
efficient  algorithm  for  execution  of  multi-process  shared  events  required  for 
implementation  of  our  constructs.  Our  implementation  extends  ”C”  for  con¬ 
current  programming  and  the  current  version  runs  on  Unix  4.3  BSD.  We  con¬ 
clude  that  the  STOCS  model  is  a  good  starting  point  for  modeling  asynchro¬ 
nous  concurrent  systems  based  on  synchronous  communication. 

2.  Future  Work 

The  novelty  and  simplicity  of  the  STOCS  model  has  opened  up  a  large 
number  of  interesting  issues  in  specification  and  analysis  of  concurrent  sys¬ 
tems.  ^^’e  now  discuss  some  open  problems  in  each  of  the  important  aspect  of 
using  the  STOCS  model. 

2.1.  Specification 

•  Reduction  of  non-determinism:  A  non-deterministic  finite  state  machine  can 
always  be  converted  to  a  deterministic  finite  state  machine.  This  fact  leads  to 
many  advantages,  as  it  might  be  easier  to  specify  a  system  using  non- 
deterministic  finite  state  machine  but  easier  to  simulate  a  deterministic  finite 
state  machine.  Along  similar  lines,  it  is  desirable  to  convert  a  non-deterministic 
STOCS  machine  to  a  deterministic  STOCS  machine  if  possible.  This  may  not 
always  be  possible  as  we  do  not  know  whether  the  family  of  languages 
accepted  by  DSTOCS  machines  is  the  same  as  that  accepted  by  STOCS 
machines.  More  research  is  required  for  algorithms  to  convert  a  STOCS 
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machine  to  a  DSTOCS  machine. 


•  Canonical  Representation  of  a  STOCS  Machine:  A  deterministic  finite  state 
machine  can  always  be  minimized  with  respect  to  its  number  of  states.  Besides 
saving  in  the  number  of  states,  this  has  the  advantage  of  providing  a  canonical 
representation  of  a  finite  state  machine.  Thus  to  check  whether  two  finite  state 
machines  are  identical,  we  need  only  convert  them  to  their  canonical  forms.  In 
an  analogous  fashion,  it  is  desirable  to  have  a  canonical  representation  of  a 
STOCS  machine  which  can  be  used  to  check  equivalence  between  two  STOCS 
machines. 

•  Language  Preserving  Transformations  on  STOCS  Machines:  A  finite  state 
machine  can  be  optimized  for  its  number  of  states  by  the  minimization  algo¬ 
rithm.  Similarly,  it  is  desirable  to  have  language  preserving  transformations  on 
STOCS  machines  which  may  minimize  the  number  of  places,  minimize  the 
number  of  units,  minimize  the  number  of  *-places,  minimize  the  non¬ 
determinism  or  maximize  the  concurrency  possible  in  the  system. 

•  Modeling  of  General  Linear  Constraints:  In  section  3.4,  we  gave  examples  of 
units  that  modeled  some  simple  linear  constraints  on  the  number  of 
occurrences  of  symbols  in  a  string,  sich  as  n^-=2n^^.  We  conjecture  that  ary 
linear  constraint  with  rational  coefficients  can  be  modeled  by  a  unit.  The  con¬ 
jecture  is  true  if  a  set  of  strings  which  satisfy  a  linear  constraint  also  satisfies 
the  property  that  there  exists  a  constant  M,  such  that  any  string  longer  than 
M  can  be  written  as  interleaving  of  strings  smaller  than  M.  A  constructive 
proof  for  the  truth  of  the  conjecture  will  provide  a  technique  to  synthesize  a 
STOCS  machine  from  a  set  of  linear  constraints. 
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•  Hierarchical  Mocieling  and  Analysis;  Hierarchical  modeling  reduces  the  com¬ 
plexity  of  the  system  by  providing  abstraction.  If  a  system  that  is  expressed 
hierarchically  can  also  be  analyzed  hierarchically,  then  a  substantial  saving  of 
computational  effort  may  be  possible  during  its  analysis.  In  STOCS  model,  an 
internal  procedure  can  be  modeled  by  a  transition.  More  research  is  required 
to  make  the  model  more  amenable  to  hierarchical  specification. 

2.2.  Relationship  with  Petri  nets 

•  Polynomial  reduction  of  reachability  in  STOCS  to  Petri  Nets:  A  free  labeled 
STOCS  can  be  directly  converted  to  Petri  Nets  in  linear  time  using  Lemma  3. 
Similarly  using  Lemma  2  reachability  problem  in  a  Petri  net  can  be  converted 
reachability  in  STOCS  using  linear  time.  However,  we  do  not  know  of  any 
method  to  transform  reachability  in  a  genera)  STOCS  to  a  Petri  net  in  polyno¬ 
mial  time. 

•  Exact  Relationship  with  Petri  Net  languages:  From  Theorem  5.3,  we  know 
that  concurrent  regular  languages  are  contained  in  Petri  net  languages.  The 
question  that  remains  to  be  answered  is;  Is  the  inclusion  proper?  In  other 
words,  are  there  Petri  net  languages  which  are  not  concurrent  regular  ?  Our 
current  belief  is  that  this  is  the  case.  Our  belief  is  based  on  the  fact  that  Petii 
net  languages  are  closed  under  concatenation  and  union,  and  this  does  not 
seem  plausible  for  concurrent  languages.  In  particular,  we  have  not  been  able 
to  construct  STOCS  machine  that  accepts  {a6)@.(6c)@. 

•  Minimum  Number  of  Connected  *-places:  *-places  are  the  only  sources  of 
unboundedness  and  therefore  it  is  desirable  to  minimize  the  number  of 
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connected  *-places.  By  our  construction,  each  unit  can  have  at  most  one  *- 
place.  Thus  the  problem  is  reduced  to  decomposing  a  Petri  net  into  units  such 
that  at  most  K  of  them  have  connected  *-places.  A  unit  assigned  the  number 
K  has  a  connected  *-place  iff  there  exists  a  transition  t  such  that  there  exist  a 
place  assigned  the  color  K  as  input  of  the  transition,  or  output  of  the  transi¬ 
tion  but  not  both.  Rephrasing  the  above,  we  get  the  following  problem: 

Ijislance:  An  ordinary  Petri  Net  N=  (P,T,I,0)  and  0<K <.  I  P\ 

Question-.  Is  there  a  function  f:P->{l,2,..,M}  such  that  f[p\)^f{P2)  whenever 
{p,  jjoleftT')  r  (p|,/;2)tC(/)for  some  fe?,  and  for  all  places  pj  such  that 
/(/;,)> A',  if  Pi€l(t)UO{f)  then  3p2‘/(P2)=/(Pi)  ^  P2^^(0uO(/). 

2.3.  Algebraic  Representation  of  a  STOCS  Machine 

•  Canonical  Representation  of  CRE's:  To  check  the  equivalence  of  two  con¬ 
current  regular  expressions,  it  is  important  to  have  a  canonical  representation 
of  concurrent  regular  expressions. 

•  Optimization  of  CRE's:  It  is  desirable  to  reduce  the  number  of  []’s  or  a’s  in  a 
given  expression.  This  problem  may  be  quite  hard,  as  a  similar  problem  for 
regular  expressions  (star-height  problem)  is  still  open. 

2.4.  The  Language  of  a  STOCS  Machine 

•  Family  of  Languages  of  k-STOCS:  A  k-STOCS  is  defined  as  a  STOCS  with 
at  most  k  units.  We  conjecture  that  the  family  of  languages  accepted  by  a  (k- 
l)-STOCS  is  properly  contained  in  k-STOCS.  Chapter  5  show  that  1-STOCS 
is  properly  contained  in  2-STOCS.  In  Garg  88,  we  have  shown  that  the  conjee- 


ture  is  true  for  FLSTOCS. 

•  Closure  Properties  of  STOCS  Languages;  STOCS  languages  are  clearly 
closed  under  synchronous  composition.  As  Petri  nets  are  not  closed  under 
Kleene  Closure,  we  also  know  that  concurrent  regular  languages  are  not 
either.  It  is  still  an  open  problem  whether  concurrent  regular  languages  are 
closed  under  +,  .,  a  and  I  1. 

2.5.  Modeling  of  Uncontrollable  Events 

•  Efficient  Construction  of  LT^E  from  UFSM:  In  this  chapter,  we  provided  an 
efficient  construction  of  UFSM's  from  LTTE’s.  Our  construction  of  URE  from  a 
ITSM.  however,  requires  calculation  of  regular  expression  for  minimal  accep¬ 
tance  set  the  UFSM.  As  a  result,  the  final  expression  has  a  single  0  but  may 
be  very  long.  We  do  not  know  of  any  method  of  exploiting  0  operator  more 
efficiently  so  that  a  smaller  expression  is  calculated  from  a  given  machine. 

•  .Axiomatic  Proof  System:  We  can  check  the  equivalence  of  two  expressions 
(machines)  if  they  could  be  converted  to  a  canonical  representation.  A.n  alter¬ 
native  method  is  to  provide  sound  and  complete  axioms  and  rules  of  inference 
such  that  any  relationship  between  two  expressions  can  be  proved. 

2.6.  Analysis  of  STOCS  Machines 

•  Analysis  of  General  Regular  Topology:  In  chapter  7,  we  saw  how  machines 
connected  in  star,  broadcast  or  ring  topology  can  be  analyzed.  Some  of  the 
other  interesting  topologies  are  regular  topologies  such  as  hyper-cube  in  which 
each  processor  has  three  neighbors.  An  interesting  task  for  investigation  is  the 
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generalization  of  these  techniques  for  identical  processes  connected  in  any  arbi¬ 
trary  topolog}-. 

•  Reachability  in  k-STOCS:  For  symbolic  reachability,  matrix  equations  led  us 
to  necessary  but  not  sufficient  conditions  for  reachability.  We  are  investigating 
efficient  techniques  which  gives  conditions  both  necessary  and  sufficient  for 
reachability  in  a  restricted  class  of  STOCS  model:  STOCS  machines  with  at 
most  k  units. 

•  Stopping  Rule  for  Induction:  For  application  of  the  induction  technique,  we 
need  to  find  a  k  such  that  the  system  with  k  processes  is  equivalent  to  a  sys¬ 
tem  with  A- -1-1  processes.  It  was  easy  in  our  examples  where  k  had  small 
values(l  and  2).  There  needs  to  be  a  more  general  algorithm  for  selecting  k. 

•  Performance  Analysis:  Timed  Petri  Nets  and  Stochastic  Petri  nets  have  beer, 
used  extensively  for  performance  analysis  of  diverse  kind  of  systems.  It  is  easy 
to  extend  definitions  of  the  STOCS  model  to  simulate  Timed  or  Stochastic 
Petri  nets,  but  it  remains  to  be  seen  if  the  modularity  in  STOCS  model  is  also 
beneficial  in  performance  analysis  of  concurrent  systems. 

2.7.  Incorporation  of  the  STOCS  model  in  a  Programming 
Language 

•  Naming:  The  current  design  uses  explicit  naming  of  processes  in  the  spirit  of 
CSP.  As  for  CSP,  this  may  prove  restrictive  and  use  of  port  names  may  be 
preferred.  We  have  chosen  to  keep  the  initial  prototype  simple  and  the  future 
design  may  include  port  names. 


•  Extension  to  Asynchronous  Communication  primitives:  The  current  process 
allows  only  synchronous  communication  primitives.  Asynchronous  message 
passing  can  be  specified  using  an  extra  buffer  process.  We  chose  to  keep  syn¬ 
chronous  primitives  only,  as  reasoning  with  asynchronous  processes  is  error 
prone  and  cumbersome. 

•  Dynamic  Process  Structure:  The  current  design  also  restricts  the  process 
structure  to  be  static.  This  implies  that  unbounded  process  activation  and 
recursive  process  activation  is  not  possible.  This  restriction  is  a  direct  conse¬ 
quence  of  our  aim  of  keeping  the  construct  analyzable. 

•  Exception  Handling,  Fairness:  The  current  design  assumes  an  error  free  reli¬ 
able  message  service.  It  also  does  not  address  the  issues  of  process  failures, 
reliability,  exception  handling  and  security.  Similarly  specification  of  priority 
and  issues  arising  due  to  fairness  concerns  are  not  considered  here.  The  notion 
of  time  is  also  missing  in  the  current  design. 

In  conclusion,  this  dissertation  is  a  first  step  towards  a  model  that  com¬ 
bines  advantages  of  net-theory  and  algebraic  theory  of  concurrent  systems. 
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/•  Apprndtt  A  */ 

/•a  program  hrre  rfjrrt  to  communication  component  of  a 
tingle  procett.  Each  proeeit  it  txippottd  to  hate  a  computational 
component  uritlen  in  C  and  a  communication  component  uritten  in 
handthake  and  unite  Handihakci  which  arc  common  to  multiple 
proctetrt  arc  replicated.  It  it  aieumed  that  the  firtt  procett 
mentioned  in  the  handthake  it  reepontihle  for  eteeuting  the 
body.  */ 

program 

'^PROCESS  'ilD  V 
configinfo 
unit 

handshake  list 


/; 

Dffinition  oj  configuraUen 

*/ 

configinfo; 

YCONFIGURATION  hostlisi  MiND  YCONFIGURATION 


hostlist:  hoftlist  MD  MD  V 

I 

'ilD  V  MD  V 


/* 

Definition  of  a  unit 

V 

unit 

A’NIT 

communitname 

unitinfo 
state  lift 

'iPND  M'NIT  V 


unitinfo; 

YSTATE  'i'Nl’MBER  V 
stateva) 
marking 
» 

suteval: 

YGONST  1'  vaJJist  T 
♦ 

vailist; 

vallist  '  valitem 

I 

valitem 
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vaiitem:  MD  '  VNU.NIBER 
marking: 

m\RKlNG  V  mlist  V  V 

mlist: 

mlist  '  miiem 

I  . 

miiem 

mitem:  MD  V  'i'Xl'MBER 

I 

m  V  '->• 

t 

/• 


Definition  of  etate  tranrilione 

V 

state_li5t: 

slaledes 

1 

state  list  statedes 


staledes; 

siateinfo  trans  list 


stateinfo: 

statename 
action  ' 


trans  list; 

transdes 

I 

trans  list  transdes 


transdes: 

■>  '  transname 
statename  action  V 


action:  YACTION 


eommunitname:  YID 


■tatename:  YID 


transname:  YID 
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/; . 

Definition  of  kandihaket 

•I 

handsh&ke  list:  handshake 

'  I 

handshake_list  handshake 

t 

handshake:  handshakeheader 
hbody 

I 

handshakeheader:  enablcinfo  YHANDSHAKE  transname 
proc  decl 

f 

enableinfo: 

I 

'^'ENABLED 

prof  decl: procedure 

I 

proc  decl  procedure 

procedure:  YTD 

r  arglist  TV 

aTgiist;arg  argiist 

I 

t 

arg:  qua!  YID  V  \TD  V 

qual:  “WAR 

I 

1 

hbody;  YACTIOX 

I 

9c^o 

#inclucle  "lex.yy.c" 
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control,  battle  management  information  processing,  surveillance 
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reliability /maintainability  and  compatibility. 
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